Substack API alternatives

Does Substack have an API

Substack's help center states: "At this time, we don't have a public API and we don't have a timeline for when/if this would become available." You can't register an application or generate a developer token to fetch your newsletter's posts.

Substack does have Developer API Terms at substack.com/api-tos, last updated 8 January 2026, for approved partners. That access covers profile-level data only: name, LinkedIn URL, social links, total subscriber count, bestseller status, leaderboard recognitions, profile summary, profile URL and publication URL. Posts aren't included, and the terms let Substack set rate limits at its discretion and forbid circumventing them.

To show recent posts on your website, you have two options: the public RSS feed, or undocumented JSON routes under /api/v1/.

The /feed URL every publication has

Every Substack publication serves an RSS feed at /feed. On a default Substack subdomain, the URL is https://<name>.substack.com/feed, and for publications on a custom domain it's https://<custom domain>/feed, such as https://www.lennysnewsletter.com/feed. When a publication has a custom domain, the substack.com URL redirects to it; the proxy follows that redirect.

The feed contains the 20 most recent posts. Each item in the XML includes:

• title
• link
• pubDate
• description (the post subtitle)
• dc:creator
• content:encoded (the post HTML)
• enclosure (a cover image, or the audio file for podcast episodes)

Substack feeds don't send an Access-Control-Allow-Origin header, so calling fetch() directly from browser JavaScript on your own site fails with a CORS error. You can get around this in the browser by putting the feed URL after https://proxy.cors.dev/, which requires no signup and no key on the free tier.

Tested on 28 October 2026 at a pace of one request every 3 seconds through https://proxy.cors.dev/, all 7 Substack feeds returned 200. Every feed stayed under the free tier's 6 MiB response limit, even with full post HTML in content:encoded.

Load the feed in the browser

To load a publication's feed from client-side JavaScript, prepend https://proxy.cors.dev/ to the feed URL, such as https://proxy.cors.dev/https://www.lennysnewsletter.com/feed. The snippet below defines latestSubstackPosts(publication, limit), fetches /feed through the proxy, retries twice on 429 after 3 and then 6 seconds, and returns the title, URL, published date, subtitle and media URL for each post.

const PROXY = 'https://proxy.cors.dev/';
const decode = (html) => new DOMParser().parseFromString(`<body>${html}`, 'text/html').body.textContent;

async function latestSubstackPosts(publication, limit = 10) {
  const feedUrl = `https://${publication}/feed`;

  // Substack answers 429 when an IP sends too much, so we back off and retry twice
  for (let attempt = 1; ; attempt++) {
    const res = await fetch(PROXY + feedUrl);
    if (res.status === 429 && attempt < 3) {
      await new Promise((resolve) => setTimeout(resolve, 3000 * attempt));
      continue;
    }
    if (!res.ok) throw new Error(`${feedUrl} answered ${res.status} (${res.headers.get('X-Cors-Source') ?? 'proxy'})`);

    const doc = new DOMParser().parseFromString(await res.text(), 'text/xml');
    return [...doc.querySelectorAll('item')].slice(0, limit).map((item) => ({
      title: item.querySelector('title')?.textContent ?? '',
      url: item.querySelector('link')?.textContent ?? '',
      published: new Date(item.querySelector('pubDate')?.textContent ?? ''),
      subtitle: decode(item.querySelector('description')?.textContent ?? ''),
      media: item.querySelector('enclosure')?.getAttribute('url') ?? null,
    }));
  }
}

console.log(await latestSubstackPosts('www.lennysnewsletter.com', 3));

The description element in Substack's XML contains HTML entities, so the snippet decodes it before returning the subtitle string. If you extend the code to read content:encoded for the full post body, treat it as third-party HTML and sanitize it before inserting it into your page.

For safe rendering, see fetching RSS feeds in JavaScript; to turn the whole feed into rss2json-style JSON, see the rss2json alternative.

Undocumented JSON endpoints

Substack publications also answer on JSON routes under /api/v1/ that aren't documented anywhere, so they can change without notice. The archive listing is smaller than the RSS feed and lets you page past the feed's 20 posts:

• /api/v1/archive?sort=new&limit=10: returns a JSON array of post summaries (43,295 bytes for 10 Noahpinion posts), and you can add &offset=10 for the next page. Fields include id, title, slug, post_date, audience, canonical_url, subtitle, cover_image, podcast_url, reactions, restacks and truncated_body_text, while body_html is empty in this listing.
• /api/v1/posts?limit=10: returns full post bodies (893,354 bytes for 10 Noahpinion posts).
• /sitemap.xml: lists post URLs in XML (1,373 post URLs in 199,659 bytes for Noahpinion).

Through the proxy on 28 October 2026, requesting /api/v1/archive?sort=new&limit=5 answered 429 for 5 of the 7 tested publications and only returned 200 for 2 of them (Simon Willison's Newsletter at 27,117 bytes, and One Useful Thing at 24,186 bytes). The /feed RSS URLs were far more reliable than the JSON endpoints across the same test.

Handling Substack's 429 responses

When Substack rate-limits a request, it returns status 429 with a 17-byte "Too Many Requests" body and no Retry-After header. When you fetch through cors.dev, that response includes the header X-Cors-Source: upstream, which tells you the 429 came from Substack and not from the proxy.

In a re-test the same day, all 7 /api/v1/archive URLs returned 200 from a server IP while most of the same requests through the proxy got 429, though 5 /feed requests in a row at one every 1.5 seconds all returned 200 through the proxy. The difference is the IP address: the free proxy's outbound IPs are shared with everyone else using it, and Substack throttles them.

By contrast, the cors.dev free tier allows about 600 requests a minute per IP for GET and HEAD requests with no daily or monthly quota, and if you pass that limit the proxy itself answers 429 with a Retry-After header. To avoid hitting Substack's upstream rate limit from browser code, follow these steps:

1. Cache in the browser

   Fetch the feed at most once per page view and keep the parsed result in localStorage or your own cache for a few minutes.

2. Back off on 429

   Wait and retry when you see a 429 status, just like the code snippet above retries twice after 3 and then 6 seconds.

3. Move steady traffic off the client

   For steady traffic, fetch the feed on your own server or at build time on a schedule rather than from every visitor's browser. Proxy caching won't absorb it: Substack feeds answer with Set-Cookie and Cache-Control: no-cache, so cors.dev Pro's X-Cors-Cache header passes them through uncached.

Good questions.