API

Authentication

Two ways in: a long-lived project API key for servers and websites, or an OAuth 2.1 token that an MCP client obtains for you. How to create them, how to send them, and how to keep them safe.

Every request to a Reblog API carries a bearer credential. There are two kinds, and they solve different problems.

	Project API key	OAuth 2.1 access token
Created by	You, in the dashboard	The client app, through a consent screen
Scope of access	Exactly one project	Every project the grant covers
Lifetime	Until you revoke it	60 minutes, refreshed automatically
Granularity	Two levels: read, or read + write	Per-capability scopes, chosen at consent time
Works on	Content API and MCP	MCP only
Best for	Your website, a build step, a script, a CI job	Claude, Claude Code, Cursor, any interactive agent

Project API keys#

1
Open the API keys screen
In the dashboard: your workspace, then the project, then API keys. The direct URL is https://reblog.so/app/workspaces/<workspace_id>/projects/<project_id>/api-keys.
2
Pick a permission level
Read only for anything a visitor's browser could get near -- a front end, a sitemap fetcher, an analytics job. Read + write for an MCP client or a script that has to create and publish.
3
Copy the private key now
Only a SHA-256 hash of it is stored. The dashboard afterwards shows you the last four characters, and nothing else. Lost it? Create a new key and delete the old one.

Level	Name	What the key can do
`2`	Read only	Read published articles through the Content API. On MCP, the read-only tool set.
`3`	Read + write	Everything a full-access connection can do on that one project, including creating, publishing and deleting.

Creating a key is itself a privileged action: it requires the project's administrator-level permission.

A private key is a server-side secret

It carries the permission level you chose, on the whole project, with no expiry. Never put one in client-side JavaScript, a mobile app, a public repository, or a URL you paste into a chat. Read it from an environment variable and call the API from your server or your build step.

Sending the credential#

Three forms are accepted, and they are tried in this order. Use the first.

# Preferred, everywhere.
curl -H "Authorization: Bearer $REBLOG_API_KEY" \
  "https://reblog.so/api/external/articles?handle=guides/getting-started"

The query parameter form is deprecated

A key in a URL ends up in access logs, proxy logs, browser history and referrer headers. Requests that use ?private_key= or ?api_key= still succeed, but the response carries Deprecation: true and a Warning: 299 header. Move to the Authorization header; nothing else changes.

OAuth 2.1, for MCP clients#

You do not create anything for this path. An MCP client discovers the Reblog authorization server, registers itself, and sends you to a consent screen where you choose what it may do and which projects it may touch. The client then holds an access token (prefix rba_) that it refreshes on its own.

Access token -- 60 minutes, sent as Authorization: Bearer rba_....
Refresh token -- 60 days, rotated on every use, with replay detection: presenting a consumed refresh token invalidates the chain.
Authorization code -- 60 seconds, single use, PKCE S256 required.
Revocation -- from the dashboard under Settings -> Connected apps, or through the RFC 7009 endpoint.

If you are building the client, the full flow is on OAuth 2.1 for app builders. If you are just connecting Claude or Cursor, you do not need any of it: see Connect a client.

Which one should I use?#

Use an API key

Your Next.js site renders articles at build time. A cron job checks for stale posts. A CI step regenerates a sitemap. Anything running unattended on a server you control.

Use OAuth

A person is driving an AI client and wants it to act as them, across several projects, with an access level they can see and revoke. This is what every MCP client does by default.

An API key also works on MCP

Point a client at /api/mcp with Authorization: Bearer <project api key> and it connects with no browser step. The trade-off: one project only, two coarse levels instead of per-capability scopes, and the connection never expires. Good for a headless agent on a server, worse for a laptop.