REST API
HTTP API reference for the InlineCMS backend.
All API routes are prefixed with /v1. Most routes require either an API key (x-inlinecms-key header) or a Bearer token (Authorization header), or both.
Authentication
Section titled “Authentication”POST /v1/auth/login
Section titled “POST /v1/auth/login”Authenticate a CMS user.
POST /v1/auth/loginContent-Type: application/json
{ "email": "editor@example.com", "password": "..." }Returns: { data: { user, token, expiresAt }, error: null }
POST /v1/auth/logout
Section titled “POST /v1/auth/logout”Invalidate the current session.
POST /v1/auth/logoutAuthorization: Bearer <token>GET /v1/auth/me
Section titled “GET /v1/auth/me”Get the current authenticated user.
GET /v1/auth/meAuthorization: Bearer <token>POST /v1/auth/refresh
Section titled “POST /v1/auth/refresh”Rotate the session token.
Content
Section titled “Content”GET /v1/content/:pageId
Section titled “GET /v1/content/:pageId”Fetch content for a page. Visitors see published entries only. Editors (with auth header) see drafts.
GET /v1/content/%2Fx-inlinecms-key: <api-key>PATCH /v1/content/:entryId
Section titled “PATCH /v1/content/:entryId”Update a content entry’s fields and/or status. Requires editor role.
PATCH /v1/content/<entry-id>Authorization: Bearer <token>x-inlinecms-key: <api-key>
{ "fields": { "content": "New text" }, "status": "published" }POST /v1/content/bulk-publish
Section titled “POST /v1/content/bulk-publish”Publish all draft entries for a page.
POST /v1/content/bulk-publishAuthorization: Bearer <token>x-inlinecms-key: <api-key>
{ "pageId": "/" }GET /v1/content/:entryId/history
Section titled “GET /v1/content/:entryId/history”Get the publish audit trail for a content entry.
Snapshot
Section titled “Snapshot”GET /v1/snapshot
Section titled “GET /v1/snapshot”The project’s published override snapshot — what a build “bakes” in. Returns
content grouped by page path, object overrides, a deterministic version hash,
and the server bakeEnabled kill-switch. Published-only and read-only. See the
Build-Time Hydration guide.
GET /v1/snapshotx-inlinecms-key: <api-key>Returns:
{ "data": { "schema": 1, "version": "sha256:324ebbfc…", "generatedAt": "2026-06-05T21:46:37.497Z", "content": { "/": [ { "instanceKey": "hero-title", "fields": { "content": "…" }, … } ] }, "objectFields": [], "objectCollections": [], "objectTypes": [], "bakeEnabled": true }, "error": null}Definitions
Section titled “Definitions”POST /v1/definitions/sync
Section titled “POST /v1/definitions/sync”Called by the SDK on mount. Registers component schemas and creates stub content entries.
POST /v1/definitions/syncx-inlinecms-key: <api-key>
{ "pageId": "/", "components": [ { "componentId": "__inline_abc123", "instanceKey": "abc123", "fields": [{ "key": "content", "type": "text" }] } ]}GET /v1/definitions/:pageId
Section titled “GET /v1/definitions/:pageId”Get component schemas for a page (used by the dashboard).
Projects
Section titled “Projects”POST /v1/projects
Section titled “POST /v1/projects”Create a new project with its first admin user. No auth required (onboarding).
POST /v1/projectsContent-Type: application/json
{ "name": "My Site", "admin": { "email": "admin@example.com", "password": "secure-password" }}Returns: { data: { project: { id, apiKey, ... }, admin: { id, email, role } } }
GET /v1/projects/:id
Section titled “GET /v1/projects/:id”Get project details. Requires auth.
PATCH /v1/projects/:id
Section titled “PATCH /v1/projects/:id”Update project settings (name, domains, CDN URL, deploy hooks). Requires admin role.
PATCH /v1/projects/<id>Authorization: Bearer <token>
{ "deployHooks": [ { "id": "prod", "type": "generic", "url": "https://api.netlify.com/build_hooks/abc" }, { "id": "gh", "type": "github", "url": "https://api.github.com/repos/me/site/dispatches", "secret": "ghp_…" } ]}deployHooks fire a rebuild on every publish (debounced) — see
Build-Time Hydration → deploy triggers.
A hook’s secret is write-only: responses include hasSecret but never the value.
POST /v1/projects/:id/rotate-key
Section titled “POST /v1/projects/:id/rotate-key”Generate a new API key. Invalidates the old one. Requires admin role.
GET /v1/users
Section titled “GET /v1/users”List all CMS users in the project.
POST /v1/users
Section titled “POST /v1/users”Create a new CMS user. Requires admin role.
PATCH /v1/users/:id
Section titled “PATCH /v1/users/:id”Update a user’s name or role. Requires admin role.
DELETE /v1/users/:id
Section titled “DELETE /v1/users/:id”Remove a CMS user. Requires admin role.
POST /v1/media/upload
Section titled “POST /v1/media/upload”Upload an image. Multipart form data with a file field.
GET /v1/media
Section titled “GET /v1/media”List all uploaded media for the project.
DELETE /v1/media/:id
Section titled “DELETE /v1/media/:id”Delete an uploaded file.
Objects
Section titled “Objects”POST /v1/objects/save
Section titled “POST /v1/objects/save”Upsert object data (scalar fields + ordered collections) in one page-shaped call. Accepts an
editor session or a read-write secret API key. Drafts unless
status: "published". See the API Keys guide for the full body shape.
POST /v1/objects/saveAuthorization: Bearer icms_sk_…x-inlinecms-project-id: <projectId> # required when the key spans >1 site
{ "status": "published", "objects": [ { "type": "property", "id": "prop_123", "fields": { "title": "…" } } ] }GET /v1/objects
Section titled “GET /v1/objects”Unified object overlay (scalar fields + collections, merged). Optional ?types=a,b. Accepts the
publishable key, a session, or a secret key.
Secret API keys
Section titled “Secret API keys”Account-owned, server-to-server keys (icms_sk_…), managed with a session (admin). See the
API Keys guide.
GET /v1/api-keys
Section titled “GET /v1/api-keys”List the account’s keys (the secret is never returned).
POST /v1/api-keys
Section titled “POST /v1/api-keys”Create a key. Body: { name, scope: "all" | "selected", projectIds?, access: "read" | "write" }.
Returns the plaintext key once.
DELETE /v1/api-keys/:id
Section titled “DELETE /v1/api-keys/:id”Revoke a key (takes effect immediately).
Webhooks
Section titled “Webhooks”Signed outbound events on publish. Admin-authed; project-scoped. See the Webhooks guide for the payload, signing, and retry semantics.
GET /v1/webhooks
Section titled “GET /v1/webhooks”List webhooks (secrets redacted) and the catalog of subscribable event types.
POST /v1/webhooks
Section titled “POST /v1/webhooks”Create a webhook. Body: { url, events: string[], description? }. Returns the signing secret
once.
PATCH /v1/webhooks/:id
Section titled “PATCH /v1/webhooks/:id”Update url, events, description, or active.
DELETE /v1/webhooks/:id
Section titled “DELETE /v1/webhooks/:id”Delete a webhook.
POST /v1/webhooks/:id/rotate-secret
Section titled “POST /v1/webhooks/:id/rotate-secret”Issue a new signing secret (returned once); the old one stops verifying.
GET /v1/webhooks/:id/deliveries
Section titled “GET /v1/webhooks/:id/deliveries”Recent delivery attempts with status, response code, and attempt count.
POST /v1/webhooks/:id/test
Section titled “POST /v1/webhooks/:id/test”Send a synthetic ping and return the delivery outcome.
POST /v1/webhooks/:id/deliveries/:deliveryId/redeliver
Section titled “POST /v1/webhooks/:id/deliveries/:deliveryId/redeliver”Re-queue a delivery for an immediate retry.
Health
Section titled “Health”GET /health
Section titled “GET /health”Returns { status: "ok", version: "0.1.0" }.