API keys: let other systems read and write your content
Issue a key, send it with each request, and read or write collections and form submissions from your own tools.
A key lets a system that isn't a person — a Zapier scenario, your own backend, a script that syncs a spreadsheet — read and write this site's content without logging in. Where the public read API is open to anyone and read-only, a key unlocks writing, reading form submissions, and reading a password-protected site.
Pro and aboveIssue a key
Settings → API keys → Issue a key. Name it after who will use it and tick what it may do:
| Allowed to | What it unlocks |
|---|---|
| Read collections | The read API, including on password-protected sites |
| Write collections | Create, update and delete entries |
| Read form submissions | Pull submissions instead of waiting for a push |
The full key is shown once, right after issuing. Copy it into the other system straight away — after you close that window only the first few characters are ever shown again. If it's lost, revoke it and issue a new one.
Optionally give the key an expiry in days. A key with no expiry works until you revoke it. Each site can have up to five keys; name them by purpose so you know which one to revoke.

Send the key with each request
Put the key in an x-api-key header. Authorization: Bearer <key> works too.
x-api-key: tsk_…<site> and <collection> below accept the short name or the identifier, same as the read
API.
Read entries
GET https://yourbrand.com/api/cms/<site>/<collection>Same parameters and shape as the public read API. With a key, responses are never cached, and each field also reports which collection it points to when it's a reference.
Create or update an entry
POST https://yourbrand.com/api/cms/<site>/<collection>/itemsSend { "slug": "blue-hat", "data": { … }, "publish": true }:
data— one value per field, keyed by the field's identifier, in the same shapes the CSV importer accepts. References are the target entry's identifier.slug— optional. If an entry with that slug already exists it's updated, otherwise created. Leave it out to derive one from the first text field.publish—truepublishes immediately; leave it out to save as a draft you can review in the console first.
Validation is the same as in the console: a missing required field, a number in a text field or a reference to an entry that doesn't exist is refused with a message saying which field, and nothing is saved.
Change or delete one entry
PATCH https://yourbrand.com/api/cms/<site>/<collection>/items/<slug or id>
DELETE https://yourbrand.com/api/cms/<site>/<collection>/items/<slug or id>PATCH merges the fields you send into the existing entry; fields you don't mention are
left as they are. Add "publish": true to publish the result. Deleting is immediate and
there's no undo — it's the same as deleting from the console.
Read form submissions
GET https://yourbrand.com/api/forms/<site>/submissions?formId=<form name>Returns the newest submissions first. limit goes up to 200; when there are more, the
response carries a nextCursor — pass it back as cursor to get the next page. Leave
formId out to read every form on the site.
For anything that should react the moment a submission arrives, use outgoing integrations instead and keep this for backfills and reports.
Keeping it safe
- A key is as powerful as a signed-in admin for what it's allowed to do. Treat it like a password: don't paste it into a page, a shared document or anywhere public.
- Revoke a key the moment you stop using the tool it was issued to. Requests with a revoked key fail immediately.
- Keys are tied to one site. A key issued on another site of yours is refused here.
- If your plan no longer includes the API, keys stay listed but stop working until you upgrade again.