The Content API is a REST interface over posts, pages and their taxonomy. It is the same API the admin console uses, so anything the console can do is available to you.
Listing content
GET /v1/posts?status=PUBLISHED&limit=20&cursor=<cursor>
Responses are cursor-paginated. Do not construct cursors yourself; they are opaque and their format will change.
{
"data": [{ "id": "pst_01H...", "title": "…", "status": "PUBLISHED" }],
"meta": { "nextCursor": "eyJpZCI6...", "hasMore": true }
}
Creating a post
POST /v1/posts
Content-Type: application/json
{
"title": "Shipping on a Friday",
"slug": "shipping-on-a-friday",
"excerpt": "Why deploy frequency is a safety property, not a vanity metric.",
"content": "# Shipping on a Friday\n\n…",
"category": "Delivery",
"tags": ["devops", "culture"],
"status": "DRAFT"
}
Slugs must be unique per project and match ^[a-z0-9]+(?:-[a-z0-9]+)*$. Sending a duplicate returns 409 with the conflicting id, rather than silently appending a suffix.
Scheduling
Set status to SCHEDULED and provide publishedAt in the future. A worker promotes the post at that time; there is no polling on your side.
Versioning
Every write creates a version. The previous state is retained for 90 days and can be restored:
POST /v1/posts/<id>/versions/<version-id>/restore
Restoring is itself a write, so it creates a new version rather than discarding history.
Rate limits
600 requests per minute per API key. Responses carry X-RateLimit-Remaining and X-RateLimit-Reset. Exceeding the limit returns 429 with Retry-After in seconds — respect it rather than backing off blindly.