This blog post describes an experimental technique that uses content delivery APIs to access content management environments in the Contentstack SaaS headless CMS. For solutions that use a limited subset of content delivery APIs, this approach could support CMS previewing environments that render saved content immediately, without the need to publish those changes to a previewing environment. THIS IS EXPERIMENTAL, NOT RECOMMENDED BY CONTENTSTTACK.
Some content management services overlap with some content delivery services. For example, both content management and content delivery expose APIs to retrieve the list of content types and entries of a content type. This *may* allow use of *some* content delivery code (intended to access published data) to access content management environments (can access unpublished data). I am experimenting with a .NET content delivery solution that use the content delivery APIs to render a website from the content management environment.
Here are the steps to make it work:
- Use a read-only content management token rather than a content delivery token.
- Use the authorization HTTP header rather than the access_token HTTP header.
- Use api.contentstack.io for the content management API; use cdn.contentstack.io is for content delivery services.
For a .NET Contentstack typed client, I made the required changes in the appsettings.Development.json file:
"ContentstackOptions": { "ApiKey": "REDACTED", // api_key // "Environment": "contentdelivery", // environment // "AccessToken": "REDACTED", // access_token "Authorization": "REDACTED", // authorization // "BaseAddress": "https://cdn.contentstack.io" "BaseAddress": "https://api.contentstack.io" },
I have not experimented extensively, and I use a minimal subset of content delivery APIs, but I have not noticed any issues yet.
If the API calls do not specify a version, then Contentstack returns the latest version of each entry by default. Organizations that need to preview specific versions may need to publish to a previewing environment before previewing changes.
GraphQL runs only in content delivery. Solutions that use GraphQL may need to publish to a previewing environment before previewing changes.
Relative to content delivery APIs, entries retrieved from content management APIs can include or exclude workflow and publishing details.
Previewing solutions should disable data caching, both on the client and the server.
Before committing to this approach, consider the full lifecycle of the application. For example, solutions that use publishing webhooks to update search indexes may need to use save webhooks to mimic that logic in the content management environment, if those functions are relevant there.