Is AI recommending you? Ask Contentstack Canoe for free
CS-log-dark.svg

Product Changelog

Stay up-to-date with all the improvements, features, and changes introduced to the product, APIs, docs, and other resources.

rss_feedSubscribe to RSS Feed

Enhancement:

  • Upgraded project dependencies to improve security, performance, and overall stability.

As part of our ongoing commitment to strengthening webhook security, we are deprecating the legacy X-Contentstack-Signature header used in legacy webhook responses.

We have upgraded our webhook security infrastructure to provide a more robust and standardized way of verifying data integrity. As part of our commitment to protecting your data, we have moved away from legacy secret keys to a Public Key Infrastructure (PKI) using the RSA-PSS algorithm. This ensures that your endpoints can verify the authenticity of Contentstack payloads with industry-standard cryptographic signatures.

What’s Changing?

  • Elimination of Shared Secrets: This update addresses a critical security risk by removing the need to expose or share "Secret Keys" in application responses. By using asymmetric encryption (Private/Public keys), your stack credentials remain entirely private.
  • RSA-PSS Signature Verification: Webhooks now include an X-Contentstack-Request-Signature header. This allows you to use a Contentstack-provided Public Key to verify that the payload was sent by us and has not been tampered with during transit.

Important: The legacy X-Contentstack-Signature header is now deprecated and will be officially decommissioned in 30 days. To avoid any disruption to your webhook services, update your webhook listeners.

Read our documentation for more information.

Breaking Change:

  • Cache persistence is now provided as a separate plugin. When using a cache policy other than IGNORE_CACHE, you must pass cacheOptions.persistenceStore. Install @contentstack/persistence-plugin and configure it using new PersistenceStore({ ... }). The SDK no longer bundles persistence logic or supports storeType in cacheOptions.

Enhancement:

  • Defined only the PersistenceStore interface (getItem, setItem) in the core SDK. The full implementation is available through the persistence plugin, resulting in a lighter core package.

Bug Fix:

  • Fixed an issue where the Sync API returned a non-Axios response, causing undefined data and recursive sync failures.

We fixed an issue in Modular Blocks where using only a numeric UID (for example, 1) could cause a 422 Unprocessable Content error when fetching references or opening the Compare Versions view. As part of this fix, Modular Block UIDs are now validated and cannot consist of only numeric values.

Why this is a breaking change

Previously, Modular Blocks allowed numeric-only UIDs, which could lead to reference resolution failures. This update enforces stricter validation when creating or updating the existing Modular Blocks with numeric-only block UIDs.

Note: Numeric-only Modular Block UIDs are no longer supported.

What you need to do

If any Modular Block UID contains only numbers, update it to include alphabetic characters (a–z). UIDs that combine letters and numbers (for example, block1, section_2, banner-1) are supported.

Warning: Updating the Modular Block UIDs may result in data loss. Proceed with caution.

This update ensures references inside Modular Blocks resolve correctly and that Compare Versions opens without errors.