Write in SpiderPublish.
Render in Your Own Code.
Keep your blog, docs, press room and changelog where your agents already publish them, and show them in a Next.js or React app on your own Cloudflare Worker, Vercel, or in a mobile app. No second CMS, no content migration, and no template you have to live inside.
Your published content, one header away
Posts, docs, press releases, changelog entries, pages, navigation and custom collections all come back as JSON from the public content API. Send X-Content-Domain with your site's domain and that is the whole setup: no API key, and drafts, scheduled and embargoed items are never returned.
# Ten newest posts from your site
curl -H "X-Content-Domain: yoursite.com" \
"https://app.spideriq.ai/api/v1/content/posts?page_size=10"The article body arrives as HTML
Single post, docs, press and changelog reads return body_html next to the stored body, so your frontend never writes its own converter. It is built to go straight into the page.
Escaped
SafeText and attributes are escaped before they reach you.
Checked Links
SchemesLink and image addresses are limited to http(s), mailto, tel and relative paths.
Placeholders
ComponentsA component inside an article arrives as an empty marked element you can replace.
A typed SDK that runs in a Worker
@spideriq/publish-sdk wraps every public read in one call. It uses only fetch, retries a failed gateway once, times out after ten seconds, returns null for a missing item and names a wrong site as SITE_NOT_FOUND instead of showing an empty blog.
import { createSpiderPublish } from '@spideriq/publish-sdk';
import { PostBody } from '@spideriq/publish-sdk/react';
const cms = createSpiderPublish({ site: 'yoursite.com' });
const post = await cms.posts.get(slug); // null if missing
return <PostBody html={post.body_html} />;Your own components, inside the article
When an author drops a pricing table or a signup block into a post, your frontend decides what it becomes. Map a component name to your own React component and the SDK swaps each placeholder for it. Anything you leave unmapped renders nothing, so an article never shows a broken widget.
Fast because you cache it, fresh because you can evict it
Every read carries cache tags: one for the site, one for the content type, one for the item. With Next.js, nextCache() stores reads in the data cache under those tags, so a changed post is one revalidateTag call, not a full rebuild.
Per Item
PreciseEvict one post when it changes. Everything else stays cached.
Per Site
BroadOne tag clears everything for the site in a single call.
Any Host
WorkersOutside Next.js, pass your own request hook, such as a Cloudflare cache setting.
Reads from your domain, writes through your server
Once your domain is verified on your SpiderPublish site, browser code on it can read your published content, booking pages and funnels directly, with no cookies and only GET and HEAD. Ask-the-docs, booking submits, funnel events and newsletter signups stay behind a route on your own server, so no other site's pages can spend your quota.
Built for three kinds of team
The content stays in one place, edited by the same people and agents. What changes is who owns the pixels.
Agencies
Client sitesBuild each client's site in your own stack while the client keeps editing in SpiderPublish.
Product Teams
In your appPut the blog, docs and changelog inside the app you already deploy, on the same domain.
Mobile Apps
NativeRead the same API from your app's backend or the device. There is no web page to match.