Content API (Fetch Your Articles)

What it is

The Content API lets your own site or app FETCH your published articles from ReachSurge, instead of hosting a webhook receiver. Your build or ISR job calls our API, gets your published articles as JSON, and renders them. There is no endpoint to host and no signature to verify. This suits static and server-rendered sites (Next.js, Astro, and similar) that rebuild to pick up new content.

It is available on Starter and above.

Not the same as the REST API

The Content API uses a different token and a different base path than the Public API:

• Content API (this article): a rsc_live_ token, Starter and above, at https://reachsurge.ai/api/content/v1. Returns your published article content.
• Public REST API: an rs_live_ key, Growth and above, at https://reachsurge.ai/api/v1. Returns SEO data (analytics, citations, competitors, authority).

The two tokens are not interchangeable. Generate a Content token under Settings, then Integrations, then Content API. It is shown once, so store it as a server-side environment variable.

When you create a token you choose its scope: "All sites" (the token reads published articles from every website on your account) or a single website (the token can only read that site's content, and requests naming any other site return a 404). Scope is fixed when the token is created. To change it, revoke the token and create a new one.

Endpoints

List parameters: website_id (optional, defaults to everything the token can read: all your sites for an all-sites token, or just its one site for a site-scoped token), limit (1 to 100, default 50), include=content (adds article bodies, caps limit at 20), updated_since (ISO timestamp, for incremental sync), and cursor (from meta.next_cursor). Only published articles are returned.

Authentication

Send the token as a Bearer header from your server. Never ship it to the browser: there is no CORS, so a cross-origin browser request fails by design.

curl -H "Authorization: Bearer rsc_live_YOUR_TOKEN" \
  "https://reachsurge.ai/api/content/v1/pages?include=content"

Rate limits are per token owner: Starter 120 per minute, Growth 300 per minute, Enterprise 1,000 per minute. Every response carries X-RateLimit-* headers, and a 429 includes Retry-After.

Pulling every article for a build

Walk the cursor until meta.next_cursor is null:

const BASE = "https://reachsurge.ai/api/content/v1";
const TOKEN = process.env.REACHSURGE_CONTENT_TOKEN; // server-side only

export async function getAllArticles() {
  const out = [];
  let cursor = null;
  do {
    const url = new URL(BASE + "/pages");
    url.searchParams.set("include", "content");
    if (cursor) url.searchParams.set("cursor", cursor);
    const res = await fetch(url, { headers: { Authorization: "Bearer " + TOKEN } });
    const { data, meta } = await res.json();
    out.push(...data);
    cursor = meta.next_cursor; // null when done
  } while (cursor);
  return out;
}

A full copy-paste example (including rendering the article in a Next.js page) lives under Settings, then API Keys, then API Docs.

Errors

A 500 is never returned as an empty list. If we cannot read your content, you get the error, not a successful response with zero articles.

FAQ

Why is my data array empty? The API returns only published articles. An empty { "data": [] } means none of your articles are published yet.

Should I use the Content API or the custom webhook? Use the Content API (pull) for static or server-rendered sites that rebuild. Use the Custom site webhook (push) if your app has a backend and wants each article the moment it publishes. Both return the same article shape, so you can switch later.

Is the content ready to render? Both content_markdown and content_html are returned. The bytes are the same ones the manual webhook sends.

AI provenance

Every response for an AI-generated article carries an ai_provenance object alongside the article:

"ai_provenance": {
  "digital_source_type": "https://schema.org/TrainedAlgorithmicMediaDigitalSource",
  "human_reviewed": true,
  "disclosure_text": "Drafted with AI assistance. Reviewed and approved by a person before publication."
}

• digital_source_type is a schema.org IPTCDigitalSourceEnumeration member stating the content was produced by a generative model. It never changes: review does not alter where text came from.
• human_reviewed says whether a person approved it before publication. It changes which sentence is accurate, not the source type.
• disclosure_text is a ready-to-render line. We supply it; rendering it is yours. We do not inject it into your content, because the bytes are contractually stable.
• disclosure_in_content: true appears on autopilot and refresh deliveries, where the sentence is already inside the content. Do not render it twice on those.

The object is absent for anything not AI-generated. This is provenance data, not a compliance service: what you publish on your own site remains your responsibility.