Contentful-style “Omit from API response” toggle to safely deprecate fields before deletion

✋ Feature Requests
1

Hi DatoCMS team :waving_hand:

I’d love to propose a feature inspired by Contentful’s “Omit from API response” capability, where you can configure a field so that it’s still editable in the CMS but no longer returned by the Delivery or Preview APIs.

What Contentful does today

In Contentful, you can go to a field’s settings and choose “Omit from API response”, which:

  • Removes the field from Content Delivery API and Preview API responses

  • Keeps the field visible and editable inside the CMS UI

  • Allows you to preview what consumers will see before deleting the field entirely

This two-step workflow helps avoid breaking frontend integrations when evolving your schema.

Why this would help in DatoCMS

Right now, removing a field in DatoCMS means an immediate change in the API schema, which can cause issues when:

  • Multiple frontends/apps/servers depend on the same model

  • Rollouts of client changes are staggered

  • You want a safe deprecation period before a breaking deletion

What would be really useful is a field-level toggle such as:

  • Expose in API: On / Off

  • Or Deprecated / Omitted status

    • When “Off”, the field is excluded from both GraphQL and REST API responses

    • The actual data stays in the CMS until permanently deleted

    • Editors and developers can verify clients are ready before final removal

Example workflow

  1. Mark field as “Omit from API response”

  2. API stops returning the field (GraphQL/REST)

  3. Clients update code at their own pace without breakages

  4. Once ready → delete the field entirely

Benefits

  • Zero-breaking-change deprecations

  • Safer schema evolutions for multi-consumer projects

  • Better control over backwards compatibility

  • Easier testing of client readiness before destructive migrations

Questions for the community

  • Is something like this already discussed or on the roadmap?

  • Are there current workarounds that teams use today?

  • How are others handling safe field deprecations with DatoCMS?

Appreciate any feedback, thanks! :raising_hands:

2

Hello @ben.cooper welcome to the community and thank you very much for the feedback!

So we understand it a bit better:

Could you clarify what you meant by “avoid breaking frontends” here, and how omitting the field from the API would improve that in practice? If the field is no longer returned (and in GraphQL if it’s no longer in the schema), any consumer still querying it would fail immediately, so it seems you’d still need to update clients first, then omit/delete. A concrete example of your rollout scenario would help a lot.

Thank you once again for the feedback!

2 Likes
3

Hey mate,

Sorry, should have been clearer.

It was more that having this sort of feature would allow people to trust a removal.

An example is currently when we do clean up on models, there’s always a worry that references have been missed so sometimes the clean up gets kicked down the road.

This sort of feature provides a bit more trust as if an issue is found in production, the config setting could be just switched back on.

I was going to request some level of analytics at a property level but it seemed OTT.

4

Wouldn’t using a sandbox environment be an easier way to get the “safe rollback” you’re after?

As an example: fork the environment, delete the field there, point your frontends to that sandbox (using the X-Environment header), and if everything looks good promote it, and if anything breaks just switch back by promoting the previous one.

That way you can do the same approach not just for fields, but also models, records, assets, basically any destructive change.

5

Sure, the only issue is managing the promotion.

If a lot of changes have occurred during that period of work, it’s not a simple promotion.

IMO, having this mechanism is a much better solution than the one above proposed as its only destructive once validation is confirmed and requires less work once complete.

I understand the approach above, but it requires more work to manage, especially for larger clients.

1 Like
6

I see, thank you for the detailed feedback!
I’ll leave the feature request open so it can be considered in the future :slight_smile: