Developer documentation
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.
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>, and every one clones the same way:
npx degit contioreach/<name> my-blog
cd my-blog
npm install
cp .env.example .env # .env.local for Next.js
# 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.