Keep fetching on the server or private build
Store a workspace API key in private configuration and call the content API from the deployed server or build process. The browser should receive the rendered article, rather than the key required to fetch it.
Choose an implementation that fits the host: a server-rendered application or a build pipeline that refreshes when content changes. Coding assistants can help implement it, but do not remove the need for a compatible production environment.
Implement the whole public blog
The installation includes a blog index, detail pages, metadata, image behaviour, links and sitemap handling. Return a real HTTP 404 for an unknown article. Preserve an existing blog's source and URLs when adding the API.
The downloadable Node reference demonstrates a new blog with these requirements. It serves the blog routes, rather than replacing the rest of a website. Mount it only on the chosen blog path and keep unrelated routes on their existing application.
Account for caching and verification
A cache can reduce API calls, but it also changes how quickly new articles and image updates appear. The reference uses a five-minute per-process cache; choose an appropriate strategy for your traffic and deployment shape.
After publishing the website, run the installation check and inspect a real public article. A working API response alone does not prove that the listing, metadata, page HTML and reader navigation are correct.
Common questions
- Can I call the API from browser JavaScript?
- The workspace key must stay private. Fetch on a server or during a private build, and render article content into the public page's initial HTML.
- Does every framework work automatically?
- No. A developer needs to fit the installation to the actual hosting and routing environment. Use the reference and verification steps to assess the completed deployment.