Updatesapi-cloudflare

What's New in Cloudflare API: Apps, Policies

7d93645dd585 → 2db10acc84d9Verified February 24, 2026

```mdx

TL;DR

  • All 100 changes in this diff are additive features — no breaking changes or deprecations are present in this update.
  • New optional properties have been added to embedded policy items across all 13 Access application subtypes, covering both request and response schemas on /accounts/{account_id}/access/apps.
  • The same schema additions propagate to the per-app and per-policy endpoints: /access/apps/{app_id}, /access/apps/{app_id}/policies, and /access/apps/{app_id}/policies/{policy_id}.
  • Two new application subtypes appear in the diff — MCP Server Application (subschema #12) and MCP Server Portal Application (subschema #13) — alongside the existing eleven subtypes.
  • Because all new properties are optional, existing integrations sending or parsing policy payloads should continue to work without modification.

    • ---

    Editor's Note: We see this as a meaningful expansion rather than routine maintenance — the introduction of MCP Server and MCP Server Portal application subtypes signals Cloudflare is extending Zero Trust Access to cover Model Context Protocol workloads, which aligns with the broader industry push to secure AI agent infrastructure. The policy schema additions are consistent across all subtypes, suggesting a deliberate effort to normalize embedded policy handling. If you're building tooling that parses Access app list responses, we'd recommend updating your schema validators now to accept the new optional fields rather than waiting for them to appear in production traffic.

    ---

    What Changed

    Feature

  • New optional fields on embedded policy items (response schema): The access_app_resp_embedded_policies component schema has been extended with new optional properties on policies/items for every application subtype returned by GET /accounts/{account_id}/access/apps. This affects all 13 subtypes:

    • - Self Hosted Application (subschema #1)

    - SaaS Application (subschema #2)

    - Browser SSH Application (subschema #3)

    - Browser VNC Application (subschema #4)

    - App Launcher Application (subschema #5)

    - Device Enrollment Permissions Application (subschema #6)

    - Browser Isolation Permissions Application (subschema #7)

    - Gateway Identity Proxy Endpoint Application (subschema #8)

    - Bookmark Application (subschema #9)

    - Browser RDP Application (subschema #11)

    - MCP Server Application (subschema #12) — newly introduced

    - MCP Server Portal Application (subschema #13) — newly introduced

  • New optional fields on embedded policy items (request schema): The access_app_req_embedded_policies component schema receives parallel additions on policies/items/oneOf[subschema #3] for the same set of application subtypes. These fields are optional in POST and PUT request bodies against /accounts/{account_id}/access/apps and /accounts/{account_id}/access/apps/{app_id}.
  • Policy-level endpoints updated: The /accounts/{account_id}/access/apps/{app_id}/policies and /accounts/{account_id}/access/apps/{app_id}/policies/{policy_id} endpoints reflect the same schema additions, keeping the standalone policy resources consistent with the embedded policy representation.
  • Two new application subtypes registered: MCP Server Application and MCP Server Portal Application are now recognized subtypes within the Access apps anyOf discriminator, expanding the set of application kinds the API can represent.

    • ---

    Who's Impacted

  • If you maintain a client library or SDK that deserializes Access app list responses, you may encounter the new optional fields on policies/items and should update your models to handle them gracefully rather than treating unknown properties as errors.
  • If you use strict JSON Schema validation on request payloads sent to /accounts/{account_id}/access/apps, the new optional fields are additive and won't invalidate existing payloads, but your schema snapshots will need refreshing to stay in sync.
  • If you're building automation that creates or updates Access applications and you want to target the new MCP Server or MCP Server Portal subtypes, you can now do so via the anyOf discriminator in the request body.
  • If your tooling enumerates known application subtypes (for example, to render a UI dropdown or generate typed configuration), the addition of subschemas #12 and #13 means your enumeration is now incomplete without an update.

    • ---

    Action Checklist

  • ☐ Pull the latest OpenAPI spec from the Cloudflare api-schemas repo at commit 2db10acc84d9 and regenerate any auto-generated client code.
  • ☐ Update JSON Schema validators that snapshot the access_app_resp_embedded_policies component to include the new optional properties on policies/items.
  • ☐ Update JSON Schema validators that snapshot the access_app_req_embedded_policies component for the same reason.
  • ☐ Review any code that switches on application subtype (e.g., switch (app.type)) and add handling for MCP Server Application and MCP Server Portal Application.
  • ☐ Check whether your deserialization layer uses strict/unknown-field-rejection mode; if so, add the new optional policy fields to your allow-list before they appear in live responses.
  • ☐ Verify that your integration tests cover all 13 application subtypes if you test against the list endpoint GET /accounts/{account_id}/access/apps.
  • ☐ Confirm that any Terraform or Pulumi providers wrapping the Access Apps API are updated or have open issues filed for the new subtypes and policy fields.
  • ☐ Review documentation or runbooks that enumerate supported Access application types and add MCP Server and MCP Server Portal entries.
  • ☐ If you use response diffing in CI to detect unexpected API changes, update your baseline snapshots to include the new optional fields.
  • ☐ Test GET /accounts/{account_id}/access/apps/{app_id} for an existing app to confirm the new optional fields appear as null or are omitted (rather than causing a parse error) in your client.
  • ☐ Test GET /accounts/{account_id}/access/apps/{app_id}/policies/{policy_id} similarly to validate the per-policy endpoint schema changes don't break existing policy reads.
  • ☐ If you have monitoring or alerting on API response shape changes, acknowledge this diff to avoid false-positive alerts.
  • ☐ Evaluate whether the new MCP Server application subtypes are relevant to any AI agent or Model Context Protocol workloads in your environment.
  • ☐ Check whether your access policy creation workflows need to be extended to support the new optional request fields on policies/items/oneOf[subschema #3].
  • ☐ Coordinate with security or platform teams to determine whether MCP Server Portal applications require new Access policy templates or approval workflows in your organization.

    • ---

    Verification

  • Commit 2db10acc84d9 — Cloudflare API Schemas repository, GitHub.

    • [https://github.com/cloudflare/api-schemas/commit/2db10acc84d90f73fbd0c0e804026b5b4fb5d328](https://github.com/cloudflare/api-schemas/commit/2db10acc84d90f73fbd0c0e804026b5b4fb5d328)

  • Cloudflare API Spec Diff — Full comparison between 7d93645dd585 and 2db10acc84d9, GitHub compare view.

    • [https://github.com/cloudflare/api-schemas/compare/7d93645dd58587341a6267930addf5c53d7e0f82...2db10acc84d90f73fbd0c0e804026b5b4fb5d328](https://github.com/cloudflare/api-schemas/compare/7d93645dd58587341a6267930addf5c53d7e0f82...2db10acc84d90f73fbd0c0e804026b5b4fb5d328)

    Last verified: 2026-02-24T23:01:41Z

    ```

    📎 Sources

    What's New in Cloudflare API: Apps, Policies | Brief Stack