Frameworks
Pick your stack and copy a working integration.
ContioReach is a REST API, so there is no SDK to install and no plugin to maintain. Every guide below builds the same three things — a content client, a listing page, and an article page — in the idioms of that framework.
Next.jsApp Router, Server Components, ISR and on-demand revalidation.
NuxtServer routes, cached readers, and tag-style cache invalidation.
AstroOn-demand rendering with a tagged response cache, or a fully static build.
SvelteKitServer load functions, private environment modules, and a tagged cache you own.
RemixRoute loaders, a tagged cache you own, and resource routes.
ReactA Vite SPA plus the small API server a browser-only app needs.
VueA Vue 3 SPA plus an API server, with head management on both sides.
GatsbyBuild-time sourcing into the GraphQL layer, fully static output, rebuilds on publish.Not listed? Anything that can make an HTTP request works. Read Getting Started for the endpoints and response shape, then follow the closest guide above — the shape of the work is the same in every framework.
However different the frameworks look, each guide does the same four things. If you are writing your own integration, these are the parts to get right.
Your ContioReach API key reads your whole workspace. It belongs in a server environment variable, never in a bundle the browser downloads. Frameworks with a server — Next.js, Nuxt, Astro with an adapter, SvelteKit, Remix, Gatsby at build time — fetch directly. Browser-only apps need a small backend of their own to hold the key.
Every call shares a base URL, an X-API-Key header, and the same two-step error check: the HTTP status, then the success flag in the body. Writing that once means the rest of your integration is query parameters.
Blog content changes when an author publishes, not on every request. Each guide uses that framework's caching primitive so your pages stay fast and your API allowance goes further.
Caching alone means an author waits for the cache to expire before seeing a post live. A publishing webhook closes that gap — every guide ends with the endpoint that receives it.
Every guide assumes these. The full reference is in the API section of this documentation.
| Detail | Value | Notes |
|---|---|---|
| Base URL | https://cms-api.contioreach.com | All endpoints are under /v1. |
| Auth header | X-API-Key | A Bearer token in Authorization also works. |
| Posts | GET /v1/blogs | Listings, filters, search, and single posts by slug. |
| Taxonomies | GET /v1/categories | Also /v1/tags and /v1/authors. |
| Envelope | { success, data, meta } | meta is present on listings, absent on slug lookups. |
| minimal | true by default | Omits the article body. Pass false on article pages. |
Check both the HTTP status and the success flag. A request that was understood but could not be fulfilled can arrive as HTTP 200 with success: false.
Every framework above has an official starter, and each guide opens with the one for its stack. They are all MIT licensed and all the same blog: pagination, category archives, a table of contents built from the article body, SEO metadata, JSON-LD, a sitemap, and a working publish webhook. Clone one and change the design.
| Framework | Repository | What it demonstrates |
|---|---|---|
| Next.js | nextjs-starter-contioreach | App Router, ISR, revalidation by cache tag. |
| Nuxt | nuxtjs-starter-contioreach | Nitro cached readers and tag-style invalidation. |
| Astro | astro-starter-contioreach | A tagged response cache, no client-side framework. |
| SvelteKit | sveltekit-starter-contioreach | A small tagged cache of its own, with stale-while-revalidate. |
| Remix | remix-starter-contioreach | The same cache, plus CDN-friendly response headers. |
| React | react-starter-contioreach | An API server holding the key, and a server-rendered page head. |
| Vue | vue-starter-contioreach | The same server, plus head management on the client. |
| Gatsby | gatsby-starter-contioreach | Build-time sourcing, an explicit schema, rebuild on publish. |
Each row is github.com/contioreach/<name>. For every framework except Vue and Gatsby, one command creates the project, installs it, and adds a read-only demo API key, so the blog runs on sample content straight away:
npx create-contioreach-blog my-blog
# skip the question with --framework next | nuxt | astro | sveltekit | remix | react
cd my-blog
npm run devA banner at the top of the site shows while the demo key is in use. Paste your own key from Developer Settings → API Keys into .env (.env.local for Next.js), restart the dev server, and the banner goes away by itself. For Vue and Gatsby, clone the repository directly:
npx degit contioreach/<name> my-blog
cd my-blog
npm install
cp .env.example .env
# add your API key, then start the dev serverThe three server-rendered starters, the two SPA starters and the static one solve caching and publishing in genuinely different ways. If you are still choosing a stack, the comparison is in each guide rather than here.
Was this page helpful?