Cloudflare API Update — Entries, Custom

Impact Assessment

Severity: Moderate

The Cloudflare DLP API has removed the discriminator keyword from the /allOf[subschema #2]/result response property across all six DLP profile and entry endpoints, affecting how API clients and generated SDKs resolve polymorphic response types on 200 responses.

---

Editor's Note: We see this as a schema cleanup rather than a functional API change — the underlying data returned by these endpoints is almost certainly unchanged, but the contract describing how clients should interpret that data has shifted. This fits a broader pattern we've observed in Cloudflare's API schema evolution, where discriminator-based polymorphism is being simplified or removed in favor of flatter, more explicit schemas. If your team uses an OpenAPI code generator (such as openapi-generator or oapi-codegen) against the Cloudflare spec, regenerating your client bindings should be the first action you take.

---

Detailed Breakdown

Discriminator Removed from DLP Entry Response

Resource: /accounts/{account_id}/dlp/entries/{entry_id}

The discriminator object has been removed from the /allOf[subschema #2]/result property in the 200 response schema for this endpoint.

In OpenAPI 3.x, a discriminator tells client tooling which concrete subschema to deserialize into when a response contains a polymorphic field. Removing it means generated clients can no longer rely on a mapping key to select the correct type at runtime — they must instead fall back to structural matching or a catch-all type.

Migration steps:

Audit any generated client code that references a discriminator property (e.g., a type or kind field) on the result object from this endpoint.

If you are deserializing manually, switch to schema-based validation rather than discriminator-key lookup.

Re-run your OpenAPI code generator against the updated spec and review the diff in generated models.

---

Discriminator Removed from Custom DLP Profile List Response

Resource: /accounts/{account_id}/dlp/profiles/custom

The same discriminator removal applies to the 200 response at this collection endpoint. Clients that list all custom profiles and branch logic based on the discriminator mapping will need to be updated.

For teams using typed response wrappers, the result field may now deserialize as a generic object or union type depending on your HTTP client library's behavior.

Migration steps:

Check any switch/case or if-else logic in your codebase that keys off a discriminator property value when iterating over profile list results.

Validate that your deserialization layer handles the absence of a discriminator gracefully (e.g., does not throw on an unexpected or missing key).

---

Discriminator Removed from Custom DLP Profile Detail Response

Resource: /accounts/{account_id}/dlp/profiles/custom/{profile_id}

This change appears twice in the diff data, suggesting it may affect both GET and another HTTP method (such as PUT or PATCH) on this resource. Both operations' 200 responses have had the discriminator removed from /allOf[subschema #2]/result.

If your integration updates a custom profile and then reads back the response to confirm the saved state, both the write-confirmation path and the read path are affected.

Migration steps:

Review response handling for all HTTP methods you call against this endpoint, not only GET.

Confirm that your profile update workflows do not rely on the discriminator to distinguish between profile subtypes in the response body.

---

Discriminator Removed from Predefined DLP Profile List Response

Resource: /accounts/{account_id}/dlp/profiles/predefined

Predefined profiles are managed by Cloudflare and are typically read-only from the account perspective. Even so, clients that enumerate predefined profiles and use the discriminator to categorize them (e.g., separating regex-based entries from keyword-based ones) will need to adopt an alternative classification strategy.

Migration steps:

Identify any filtering or categorization logic applied to the result array from this endpoint.

Replace discriminator-key checks with field-presence checks or explicit profile_type field comparisons if those fields remain in the response body.

---

Discriminator Removed from Predefined DLP Profile Detail Response

Resource: /accounts/{account_id}/dlp/profiles/predefined/{profile_id}

Like the custom profile detail endpoint, this change appears twice in the diff, indicating multiple operations are affected. The result property in 200 responses no longer carries a discriminator.

Migration steps:

Re-examine any code paths that fetch a single predefined profile and branch on the discriminator value.

Ensure integration tests cover the deserialization of this response without a discriminator hint.

---

Discriminator Removed from Generic DLP Profile Detail Response

Resource: /accounts/{account_id}/dlp/profiles/{profile_id}

This is the most broadly scoped endpoint, as it resolves profiles regardless of whether they are custom or predefined. The removal of the discriminator here is particularly significant for clients that use this unified endpoint to handle both profile types through a single code path — the discriminator was likely the mechanism for distinguishing between them.

Migration steps:

Determine whether your code uses this endpoint as a unified resolver or routes separately to /custom/{profile_id} and /predefined/{profile_id}.

If using this endpoint as a unified resolver, implement type detection based on available response fields (such as type, entries, or other structural indicators) rather than the discriminator.

Update any OpenAPI-generated model factories that previously used the discriminator mapping to instantiate the correct subclass.

---

Before You Upgrade

1. Inventory all DLP API consumers in your codebase by searching for references to the affected path patterns: dlp/entries, dlp/profiles/custom, dlp/profiles/predefined, and dlp/profiles.

2. Search for discriminator-dependent deserialization by grepping for any property name that was used as the discriminator key (e.g., grep -r "discriminator\|profile_type\|\.kind\|\.type" ./src adjusted to your project structure).

3. Pull the latest Cloudflare API spec from the repository at commit 1bdaded192b7 and compare it against your currently pinned version:

```bash

curl -O https://raw.githubusercontent.com/cloudflare/api-schemas/1bdaded192b7d9298d31b04775edc83bb8a1c5fe/openapi.yaml

```

4. Run your OpenAPI code generator against the updated spec in a feature branch and produce a diff of the generated output:

```bash

openapi-generator generate -i openapi.yaml -g -o ./generated-new

diff -r ./generated-old ./generated-new

```

5. Review generated model classes for any that previously extended a discriminator-mapped base class — these may now be generated as plain structs or interfaces without a type selector.

6. Execute your existing DLP integration tests against the Cloudflare staging environment (if available) to confirm that response deserialization succeeds without the discriminator hint.

7. Check third-party SDK versions — if you rely on a community or official Cloudflare SDK rather than a self-generated client, verify whether the SDK maintainer has published an update reflecting this schema change before upgrading your dependency.

8. Review any API response caching layers that may store serialized result objects keyed by discriminator value; cached entries may deserialize incorrectly if the cache was populated under the old schema.

9. Update your schema validation middleware (e.g., ajv, jsonschema, or similar) if you validate inbound API responses against a stored copy of the Cloudflare OpenAPI spec — the old spec will now produce false validation failures on the discriminator field.

10. Document the change in your team's API changelog so that future developers are aware that discriminator-based branching on DLP result responses is no longer schema-supported.

---

Sources & Timeline

| Source | URL | Last Verified |

|--------|-----|---------------|

| Commit 1bdaded192b7 | [github.com/cloudflare/api-schemas/commit/1bdaded192b7](https://github.com/cloudflare/api-schemas/commit/1bdaded192b7d9298d31b04775edc83bb8a1c5fe) | 2026-02-24 |

| Cloudflare API Spec Diff (10a4f5ba3d0e → 1bdaded192b7) | [github.com/cloudflare/api-schemas/compare/10a4f5ba3d0e...1bdaded192b7](https://github.com/cloudflare/api-schemas/compare/10a4f5ba3d0e69ce45c5f077193051ab427ddbcd...1bdaded192b7d9298d31b04775edc83bb8a1c5fe) | 2026-02-24 |