Start free. Scale as your blog grows.Get started

Developer documentation

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.

Choose your 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.

What every integration needs

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.

1. Keep the API key on the server

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.

2. Write one request helper

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.

3. Cache the responses

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.

4. Revalidate on publish

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.

  1. An author publishes in ContioReach
  2. ContioReach POSTs your webhook URL
  3. Your endpoint verifies the shared secret
  4. Cached content is marked stale
  5. The next visitor gets the new post

The API in brief

Every guide assumes these. The full reference is in the API section of this documentation.

DetailValueNotes
Base URLhttps://cms-api.contioreach.comAll endpoints are under /v1.
Auth headerX-API-KeyA Bearer token in Authorization also works.
PostsGET /v1/blogsListings, filters, search, and single posts by slug.
TaxonomiesGET /v1/categoriesAlso /v1/tags and /v1/authors.
Envelope{ success, data, meta }meta is present on listings, absent on slug lookups.
minimaltrue by defaultOmits 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.

Start from a working repository

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.

FrameworkRepositoryWhat it demonstrates
Next.jsnextjs-starter-contioreachApp Router, ISR, revalidation by cache tag.
Nuxtnuxtjs-starter-contioreachNitro cached readers and tag-style invalidation.
Astroastro-starter-contioreachA tagged response cache, no client-side framework.
SvelteKitsveltekit-starter-contioreachA small tagged cache of its own, with stale-while-revalidate.
Remixremix-starter-contioreachThe same cache, plus CDN-friendly response headers.
Reactreact-starter-contioreachAn API server holding the key, and a server-rendered page head.
Vuevue-starter-contioreachThe same server, plus head management on the client.
Gatsbygatsby-starter-contioreachBuild-time sourcing, an explicit schema, rebuild on publish.

Each row is github.com/contioreach/<name>, and every one clones the same way:

Terminal
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 server

The 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.