API Change Log

To keep our platform up to date, we may occasionally add new resources, new fields, new response keys to the Contentstack APIs, or change the existing resources. All such changes and upgrades are documented here.

Dec 16, 2020

We have stopped supporting Access Token for all stacks created post this release, i.e., December 16, 2020. For stacks created after this release, the Access Token will no longer be generated. Instead, you need to use the value of the environment-specific Delivery Token against the ‘access_token’ key to make authorized Content Delivery API (CDA) or CDN requests. Subsequently, you can use Management Tokens to make Content Management API (CMA) requests.

For stacks created before December 16, 2020, we will continue to support Access Tokens. However, we strongly recommend switching to Delivery Tokens and Management Tokens for the respective API requests mentioned above.

Read our FAQs on Access Token Removal to know more.

Note: Though we have stopped supporting Access Tokens, we haven’t removed the usage of the ‘access_token’ key for Content Delivery API requests. To make authorized Content Delivery API requests, you need to now pass the value of the delivery token against the access_token key.

Read More

Dec 4, 2020

Adding support for the include_fallback query parameter for the following Content Delivery API requests: Get All Entries, Get Single Entry, Get All Assets, and Get Single Asset.

Using the include_fallback=true parameter in the above API requests, you can fetch published content from the fallback languages, if the requested entry is not available for the specified language.

You can refer to our API documentation on entries and assets to learn more about retrieving published fallback content. Additionally, you can learn more about this feature in our Retrieve Fallback Language Content for Published Entries guide.

Read More

September 25, 2020

Post this release, i.e. September 25, 2020, all entry-related API requests that hit the Content Delivery API (CDA) or CDN and Content Management API (CMA) will return the _metadata key inside the multiple “Group” and “Global” fields or “Modular Blocks”. This key helps to uniquely identify each instance of the above fields when they have been marked as “Multiple”.

Read More

August 31, 2020

We have deprecated the include_workflow parameter for all Content Delivery API (CDA) or CDN requests. For stacks created post this release, i.e., August 31, 2020, users will no longer be able to fetch workflow stage details for published entries. However, for stacks created before this release, users will be able to retrieve workflow stage details for existing published entries. Read more about adding workflows and workflow stages.

Read More

Jun 24, 2020

Following changes have been introduced to new stacks of Organizations created post this release, i.e., June 24, 2020:

  • Users will no longer be able to use the stack Access Token to make authorized Content Delivery API (CDA) or CDN requests. Instead, you need to use the value of the environment-specific delivery token of the stack against the access_token key. Read more about the relevant authentication parameters.
  • Users will no longer be able to pass authentication parameters such as api_key (Stack API key), access_token (Access Token of the stack), authtoken (user-generated authtoken), and authorization (Management token of the stack) as query parameters for any stack-specific API requests. Read more about Queries.

Read More

Oct 18, 2019

  • Management Token is a stack-level read-write token that lets you make authorized Content Management API requests. The token value needs to be passed in the new authorization header parameter. Read more about this token in the Authentication section.
  • The Get executions of a webhook API request will return a maximum of 100 records while fetching the execution details for a specific webhook. Previously, there was no limit on the number of records returned.

Read More

July 29, 2019

The Reference field has been upgraded to include references to more than one content types.

The input format of your Reference field has been changed from an array of strings to an array of objects. The change in the Reference field format is as follows:

    "ref_field": ["entry_UID1", entry_UID2, ...]
    "ref_field": [{
            "uid": "entry_UID",
            "_content_type_uid": "referred_content_type"
        }, {}, ...

Read More

March 08, 2019

The webhook data of an entry or asset that is published or unpublished via release deployment now includes a source key that contains the (type, title, and uid) of the source (i.e., release). Here's an example of the key that is added to the webhook data:

"source": {
    "type": "release",
    "title": "{{release_title}}",
    "uid": "{{release_uid}}"

Read More

Oct 14, 2017

  • The URL of assets for stacks created after this release will include the file name, and the URL pattern will be /v3/assets/:api_key/:asset_uid/:token/:filename. To enforce the changes on images of existing RTE or Markdown fields, you need to re-upload the images and then re-publish the entry for the changes to reflect. For more information, contact us.
  • It will now be possible to get entries by URL even if the entries use default URL pattern. This change will be applicable only to the stacks created after this release.
  • Entries that have empty URL after the upgrade, the user will have to re-save the entry to get them autopolulated in the URL field.

Read More

June 24, 2017

  • The publish_details key that was available in the response of GET requests of draft entries and assets will be no longer returned by default. To include it in the response, use the include_publish_details parameter.
  • The publish_details key available in the response of GET requests of entries and assets of specific environment(s) will now contain the details of only the environment(s) specified in the environment parameter, and not of all the environments.
  • The image URL, when opened in the browser will render the image, instead of downloading it.
  • Any API request will return a maximum of 100 records (changed from 1000 earlier). The next batch of records can be retrieved by making the same request and changing the skip parameter to 100 from 0.

Read More

Oct 30, 2016

  • With the introduction of the new V3 APIs, there is a change in response of several API requests. These are breaking changes, and may require you to adjust your code. Click the 'Read more' link below to see what changed. 

Read More

Was this article helpful?

Thanks for your feedbackSmile-icon

On This Page