Keyless reads

Reading your published content from Ghost Writr needs no API key. The site ID is the read capability, and every SDK is built around that single fact.

The site ID is the capability

Your siteId is an unguessable UUIDv7. Knowing it is sufficient to read the site’s feed, and because the id space can’t be enumerated, no one can discover or read another site’s content by guessing. There is one identifier to share and nothing extra to provision.

import { fetchArticles } from "@ghostwritr/feed";

// The siteId is the only credential. No key, no token, no header.
const articles = await fetchArticles({ siteId });

Every framework SDK reduces to the same configuration. @ghostwritr/next is createGhostwritr({ siteId }); @ghostwritr/astro is ghostwritr({ siteId }); @ghostwritr/react-router and @ghostwritr/feed take { siteId } on each fetch. None of them accept — or want — an API key for reads.

No authed fallback

The only read path is the public static feed at feeds.ghostwritr.io/{siteId}/. The keyless SDKs do not fall back to a dynamic authenticated endpoint when a file is missing. They fail closed: a missing feed throws a GhostwritrError with code NOT_FOUND rather than reaching for a privileged path.

Fallback is a server concern, not a client one

Ghost Writr’s projection layer keeps a dynamic endpoint authoritative on the server side, but that is internal. The SDK you ship never reaches it. From the client’s perspective there is exactly one source: the static snapshot. See The content feed.

Safe at the edge

Because the read client carries no secret, it is safe wherever your code runs — server components, static export, edge functions, and the browser. There is no key to leak in a bundle, no env var to guard, no origin restriction to configure. The worst case for a leaked site ID is that someone reads content you already published publicly.

This is what makes <ArticleContent> and the keyless fetchers usable in client components and at build time without ceremony.

Reads are keyless; writes are separate

Publishing is not part of the SDK surface, and you do not need it to render a blog.

	Read	Write
Credential	siteId (public, unguessable)	a separate write key
Where	static feed on feeds.ghostwritr.io	the authoring/engine side
In the SDKs	yes — every read goes through it	no — SDKs are read-only
Safe to ship to the client	yes	no

The write key lives entirely on the authoring side and is write-only — it never appears in a read SDK, a page, or a bundle. If you are wiring up a frontend, you only ever touch the read path, and the read path is keyless.

What to reach for next

The content feed The static snapshot your reads come from, and how the SDK walks it.

Error handling Why a missing feed is NOT_FOUND, and how fail-closed works.

The article shape What every read returns.