Starting April 21st, 2025, we are switching to RE2 as our regular expression engine, specifically the RE2JS npm package. This will enforce stricter validations for regular expressions in the Content Management API (CMA). From this date, you will no longer be able to publish entries with any regular expressions match or prohibit rules that are not accepted by the regular expression engine.

The previous date for this change was March 21st, 2025, however, to accommodate our customers' needs, we are pushing the date. For more information, see the previous changelog, and the Regular Expression (Regex) page.

Starting March 21st 2025, we are switching to the regular expression engine RE2. This will enforce stricter validations for regular expressions in the Content Management API (CMA). From this date, you will no longer be able to publish entries with any regular expressions match or prohibit rules that are not accepted by the regular expression engine.

We are switching to the RE2 engine as it provides more security and better performance compared to the regular engine.

What you need to do:

To continue publishing entries with offending regular expression validation rules, you need to rewrite these regular expressions and check if they are accepted by the new engine.

One way to do that is to try it out on this Playground, or you can make sure it does not include anything listed in the unsupported rules of RE2.

Starting February 17th, 2025, the GraphQL Content API will support the Embargoed assets feature for relevant customers. This enhancement extends the functionality of embargoed assets, allowing authenticated access to restricted assets directly through GraphQL queries.

Embargoed assets restrict public access to content by requiring that all requests include a dynamically generated signature. When enabled, these assets are served from the ***.secure.ctfassets.net domain.

For more details, see the Embargoed Assets page and the Asset keys section of the GraphQL API page.

On February 17th, 2025, we are releasing an update to resolve an issue where the query complexity was miscalculated when the limit argument was set to 0.

After this update:

When the limit is omitted or explicitly set to 0, a default limit of 100 will apply.

This change ensures consistent behaviour across all Contentful APIs, including GraphQL API, Content Delivery API (CDA), and Content Preview API (CPA).

What you need to do:

We recommend reviewing any queries that use a limit of 0 to ensure they align with this updated behaviour. This only affects a very small number of our customers who have also been notified via email.

See GraphQL Content API - Complexity Limits for more details.

The Content Management API (CMA) now supports marking taxonomy validations as required on content type metadata.

Once a particular taxonomy validation has been marked required for a given content type, any entry of that content type will be checked on publish to determine if the entry has taxonomy concepts assigned which fulfill the required validation(s) from the relevant content type.

To make use of this feature, a new required boolean property on the link to the taxonomy concept or concept scheme can be sent in POST, PUT, and PATCH requests for content types.

Once the feature is live, this new property will always be returned on the content type and defaulted to false.

For more information on the Content Type endpoint, see the documentation.

We are announcing a further postponement of the enforcement of stricter validation for required fields in the Content Management API (CMA) to accommodate our customers during the upcoming busy holiday and retail periods.

The new enforcement date will now be 21st January 2025.

After this date, entries with any required fields left empty will not be publishable, even if these fields are hidden in the field editor. If a field’s validation is set as both disabled: true and required: true but is left empty, a validation error will occur. We will then reveal the hidden fields so that a value can be input.

Thank you for your understanding as we aim to make this transition as seamless as possible. Please reach out if you have questions or need support in preparing for this update.

For more information about the upcoming change and how to migrate, see the Validations for hidden and required fields page and the Content Management API page.

Starting November 14th 2024, we are implementing stricter validation for required fields in the Content Management API (CMA). From this date, entries with any required fields left empty cannot be published, even if these fields are hidden in the field editor. If a field’s validation is set as both disabled: true and required: true but is left empty, a validation error will occur.

Scheduled publish actions that meet this criterion will also be impacted.

What you need to do:

To continue publishing entries with hidden fields, change the validation of these fields to optional (required: false).

Starting with March 20th, you will no longer be able to save an entry through the Content Management API (CMA) with a locale that was not previously configured, even if the X-Contentful-Skip-Transformation header is present.

After March 14th, 2024, the generated GraphQL type for ResourceLink fields will change from a type to an interface and for each field a new type will be generated that implements the ResourceLink interface. The name of the generated type will be derived from the content type name and the field name. For example, if an content type LandingPage has a reference field headline, the new type name will be LandingPageHeadline. If LandingPage has a multi-reference field called testimonials, the generated type will be LandingPageTestimonialsCollection. Additionally, the type field in ResourceSys type will be removed.

The following is an example of a content type LandingPage that has two ResourceLink fields, headline and testimonials and it illustrates the change in the generated schema:

Old schema

type ResourceLink {
  sys: ResourceSys!
}

type ResourceSys {
  type: String!
  urn: String!
  linkType: String!
}

type LandingPage implements Entry {
  sys: Sys!
  slug(locale: String): String
  title(locale: String): String
  headline(locale: String): ResourceLink
  richTextField(locale: String): LandingPageRichTextField
  testimonials(locale: String): LandingPageTestimonialsCollection
}

type LandingPageTestimonialsCollection {
  total: Int!
  skip: Int!
  limit: Int!
  items: [ResourceLink]!
}

type LandingPageRichTextField {
  json: JSON!
  links: LandingPageRichTextFieldLinks!
}

type LandingPageDescriptionLinks {
  entries: [LandingPageRichTextFieldEntries!]
  assets: [LandingPageRichTextFieldAssets!]
  resources: [LandingPageRichTextFieldResources!]
}

type LandingPageRichTextFieldResources {
  block: [ResourceLink!]
  inline: [ResourceLink!]
  hyperlink: [ResourceLink!]
}

the new schema:

# Changed from type to interface
interface ResourceLink {
  sys: ResourceSys!
}

type ResourceSys {
  # `type` field is removed
  urn: String!
  linkType: String!
}

type LandingPage implements Entry {
  sys: Sys!
  slug(locale: String): String
  title(locale: String): String
  headline(locale: String): LandingPageHeadline
  richTextField(locale: String): LandingPageRichTextField
  testimonials(locale: String): LandingPageTestimonialsCollection
}

type LandingPageHeadline implements ResourceLink {
  sys: ResourceSys!
}

type LandingPageTestimonialsCollection {
  total: Int!
  skip: Int!
  limit: Int!
  # Changed from ResourceLink to LandingPageMultiReferenceItem
  items: [LandingPageTestimonialsItem]!
}

type LandingPageTestimonialsItem implements ResourceLink {
  sys: ResourceSys!
}

type LandingPageRichTextField {
  json: JSON!
  links: LandingPageRichTextFieldLinks!
}

type LandingPageDescriptionLinks {
  entries: [LandingPageRichTextFieldEntries!]
  assets: [LandingPageRichTextFieldAssets!]
  resources: [LandingPageRichTextFieldResources!]
}

type LandingPageRichTextFieldResources {
  block: [LandingPageRichTextFieldResourcesBlock!]
  inline: [LandingPageRichTextFieldResourcesInline!]
  hyperlink: [LandingPageRichTextFieldResourcesHyperlink!]
}

type LandingPageRichTextFieldResourcesBlock implements ResourceLink {
  sys: ResourceSys!
}

Starting with Monday, August 29th 2022, when the schema generation fails, our GraphQL API returns a 422 HTTP status code instead of a 500 HTTP status code.

Our GraphQL API can currently fail on three scenarios during the generation of your schema:

• Colliding type names
• Colliding field names
• Reserved field names

For more information on how schemas are generated, see the Schema generation section on the GraphQL Content API page.

Before the fix, these scenarios led to an error with a HTTP status code of 500 for any request until the user took specific action to fix the issue. As this is considered an issue on the client side, a HTTP status code of 422 is returned from August 29th.

Starting with Monday, July 13th, the behaviour of the localization feature changes as follows:

• When using the locale=* query parameter with unlocalized fields, the API endpoints for entries will no longer return field values related to locales different to the environment default one.

Note that the current behavior of returning all the locales for a non-localized field was a bug that emerged when the user modified a previously localized field to unlocalized.

Consider the following example comparing the two behaviors:

Given an entry with two fields, where the first is localized and the second was set to unlocalized after being initially localized, the API returns:

On Wednesday 19th January, we will deprecate the boilerplate-api endpoint, which was formerly used to access pre-configured Contentful projects. The related contentful-cli “contentful boilerplate” command will also be deprecated at the same time.

These resources can now be accessed more easily from Contentful's Github. Therefore, to keep our APIs streamlined we are deprecating the unneeded endpoint.

The character limit for space naming will be extended from 30 to 64 on July 26th.

This means that admins have more flexibility when naming a space, making it easier for them to adhere to existing naming conventions within their organization. No existing spaces will be affected.

To learn more about creating a space, you can check out our help center.

When fetching content using the Contentful REST APIs the select operator allows you to choose which properties you'd like to retrieve from an entity. However, since the introduction of Tags, the API always returns an extra metadata.tags property.

This is an unintentional behavior that increases the response size. We plan to fix this behavior so that when the select operator is present we only return specified properties.

If you're using select operator and rely on the extra metadata.tags in the response, make sure to include metadata.tags property in the select operator value.

Read more about the select operator in the API documentation.

The time that it takes to receive an update for the auto_save webhook will decrease from 20 seconds to 5 seconds for content that has been changed in the Web App.

Q: Why is this being done?

We are deprecating a legacy service that had prevented closer to real-time updates for entry and asset updates from being called quicker.

Q: How does this affect me?

The time that it takes to receive an auto save update via webhooks for a web app change will decrease. Changes made in the web app will call the webhook after five seconds as opposed to after 20 seconds.

If you are consistently editing an entry in the web app for one minute, and you have a webhook configured to be called for auto_save events, that webhook will be called 12 times in a minute whereas previously the webhook would be called 3 times in a minute.

Please note that the date for this change to take effect has changed from August 10th to August 17th.

There is currently no default search order set in the Contentful Content APIs. When a collection is requested, the order in which entities are returned is unpredictable. This has been causing an issue where sometimes pagination of the unpredictably ordered list results in duplicated or missing entities in the response.

On January 13, 2020, we will be setting a default order for requests to the Contentful APIs. This default ordering will be:

DESC by sys.updatedAt,
ASC by sys.id

If you are currently using ordering in your queries using the order query parameter then you will be unaffected by this change.

If you rely on the default ordering in our API responses and do not use the order query parameter, you may be affected by the change. We encourage you to implement the order parameter or ensure you are ready for the change in default result set ordering.

There is currently no default search order set in the Contentful Content APIs. When a collection is requested, the order in which entities are returned is unpredictable. This has been causing an issue where sometimes pagination of the unpredictably ordered list results in duplicated or missing entities in the response.

On January 13, 2020, we will be setting a default order for requests to the Contentful APIs. This default ordering will be:

DESC by sys.updatedAt,
ASC by sys.id

If you are currently using ordering in your queries using the order query parameter then you will be unaffected by this change.

If you rely on the default ordering in our API responses and do not use the order query parameter, you may be affected by the change. We encourage you to implement the order parameter or ensure you are ready for the change in default result set ordering.

Related to https://www.contentfulstatus.com/incidents/5mx2zyt96c4t

As of October 31st, 2019 the following product domains will no longer be supporting TLS versions 1.0 and 1.1. That means TLS 1.2 (with HTTPS) will be required to use services available via a specific domain:

• api.contentful.com
• app.contentful.com
• assets.contentful.com/assets.ctfassets.net
• downloads.contentful.com
• images.contentful.com
• preview.contentful.com
• static.contentful.com
• upload.contentful.com
• videos.contentful.com

Q: Why is this being done?

With the earlier versions of TLS/SSL, there have been security vulnerabilities identified that rendered these protocol versions unsafe. We already see less than 1% of all API traffic to be using older versions of TLS, and we believe this change will help the rest of customers to make the switch to more reliable and safer versions of TLS protocol.

Q: How does this affect me?

We have contacted most of the customers using TLS 1.0 and/or TLS 1.1 with our APIs. If we have not contacted you and you are unsure if and how this change affects your app or site please feel free to reach out to Contentful Support. We are also happy to assist with the migration.

As of October 31st, 2019 Contentful's Management API will no longer be supporting TLS versions 1.0 and 1.1. That means TLS 1.2 will be required for using the Management API with HTTPS.

Q: Why is this being done?

With the earlier versions of TLS/SSL, there have been security vulnerabilities identified that rendered these protocol versions unsafe. We already see less than 1% of Management API traffic to be using older versions of TLS, and we believe this change will help the rest of customers to make the switch to more reliable and safer versions of TLS protocol.

Q: How does this affect me?

We have contacted most of the customers using TLS 1.0 and/or TLS 1.1 with Management API. If we have not contacted you and you are unsure if and how this change affects your app or site please feel free to reach out to Contentful Support. We are also happy to assist with the migration.

With this change we'll stop to provide default widgetId properties for controls of EditorInterface entities when generating them automatically for newly created or updated Content Types. The consuming application should determine the default widget ID on its own.

The Contentful Web App is the primary consumer of this API. It already doesn't rely on this behavior.

This change concerns you only if you maintain your own replacement of the Contentful Web app and reuse EditorInterface entity for management of its appearance.

This change impacts any non-master environment relying on the current behavior allowing the creation of more resources (locales, content types, records, assets, or entries) beyond the limits allocated by your space plan. You can review those limits here.

Once this change takes place, it will no longer be possible to create items for any resource type that exceeds your plan limits in any environment. These enforcements have always been in place for the master environment and now will be extended to all space environments.

Enforcing these existing limits will allow us to release and support some exciting upcoming features for space environments to enhance release workflows.

With this change we'll be introducing pagination to the collection endpoints for the Extension entities:

• /spaces/:spaceId/extensions
• /spaces/:spaceId/environments/:envId/extensions

Right now calling the collection endpoint will always use unmodifiable skip and limit parameters set to 0, the API will ignore them and return an Array of all Extension entities in an environment. This behavior is incorrect and inconsistent with the rest of collection endpoints.

After the change is released only the first page of results will be returned. Further pages can be queried using standard skip and limit query string parameters as described in Search Parameters reference.

The GraphQL Content API currently has a query complexity limit of 11000 for all queries. A few customers were temporarily excluded from this limitation based on the complexity of their prior queries sent to the API. Starting May 31, 2019, however, this exclusion will no longer apply to those free and on-demand customers who currently have exceptions. There’s plenty of time left until May 31, but please double check that all your queries fall under the 11000 limit so that your apps keep working smoothly.

This change will change how UI Extensions are rendered in the Web App.

The following changes will be made:

• when the extension page will be reloaded, UI Extensions SDK will be reinitialized in the frame
• when the extension page will navigate away, UI Extensions SDK will be reinitialized in the target location (if included)
• when the extension page submits a form, the target URL will be hit with a POST HTTP request and the UI Extensions SKD will be reinitialized in target location (if included)

Extensions that are built correctly will continue to operate normally. You'll need to change the logic of your extensions if they rely on the following behaviours:

• reloading an extension page including UI Extensions SDK shouldn't use the SDK after the reload
• navigating to a different page including UI Extensions SDK shouldn't use the SDK after the navigation
• form sumbmission being prevented by browser protection mechanisms, not explicit code call

We are removing the legacy collection endpoint for Editor Interface entities in the Content Management API:

/spaces/:spaceId/environments/:envId/content_types/:ctId/editor_interfaces/:interfaceId

This endpoint was removed from our documentation, tooling and the Web App in early 2016 and replaced with a subresource of a Content Type. Since then it was kept in place only for backwards compatibility. We didn't register any requests to the endpoint in several months and hence are going to deprecate it.

As of today, any authenticated user with access to a space can perform all operations on UI Extensions (reading an extension, creating a new extension, updating or deleting an existing extension). This was allowing users with limited access to a Contentful space to compromise the experience by, for example, deleting a UI Extension.

In order to improve security applied on mutative UI Extensions operations, we are proceeding with a change that will result in granting permissions to create, update and delete UI extensions only to spaces administrators. The behaviour for "read" operation will remain the same: any authenticated user with access to a space can read its UI Extensions.

The Contentful Web App and any applications using our delivery APIs will not be affected by this change. If you are using a non-admin access token to interact with UI Extensions (e.g. in scripts or CI) please replace it with an admin access token.

We plan to fix an inconsistency between the preview and delivery APIs which led to unability to resolve linked entries when fetching entries using locale=*.

When calling the https://preview.contentful.com/spaces/{spaceid}/entries/?locale=* endpoint, the locale property won't be present in the sys, just like when calling https://cdn.contentful.com/spaces/{spaceid}/entries/?locale=*.

While this is fixing an inconsistency, any program relying on having the locale property in the sys object on preview API calls using locale=* could break so we invite you to update these.