Create an API key and choose what it can do
One key per integration, scoped to exactly the capabilities it needs. You see the key once.
Everything outside the web app, an agent over MCP, the CLI, plain HTTP, authenticates with an API key. Keys belong to your organization, are created by an admin, and carry a list of capabilities that say what the key may do.
Create a key
- Open Settings → API Keys (admins only; editors see the tab disabled).
- Press New Key.
- Name it after what will use it: "Claude Code", "CI publisher", "Zapier".
- Tick the capabilities it needs. A new key starts with only
article:read. One-click presets fill the list for you: Onboarding agent, Onboarding + publishing agent and Read only. Select all suits a personal key you'll use from your own agent. - Optionally change the rate limit in requests per minute (default 1000).
- Press Create Key. The key is shown once. Copy it somewhere safe now; it can't be shown again.
Keys start with ls_. Older keys starting with lb_ still work.
Pick capabilities by what you'll do
| If you want to… | Grant |
|---|---|
| Read posts, collections, published pieces | article:read |
| Create drafts | article:write |
| Publish or unpublish | article:publish |
| Run a writing kernel and poll it | kernel:read, kernel:write |
| Run an arena (research) and poll it | arena:read, arena:write |
| Shred a document | shredder:read, shredder:write |
| Run a seer, read its events | seer:read, seer:write |
Re-run an Enhance pass on a post and poll it (run_enhance_pass/get_enhance_run) | article:write, article:read |
| Write a post end to end, and configure a publication | collection:read, collection:write |
| Create, configure, or tear down a phantom site, or connect a domain you own | phantom:read, phantom:write |
| Buy a custom domain | phantom:domain |
| Read positioning and competitors | provisioning:read |
| Set positioning, add or remove competitors | strategy:write |
| Import a sitemap | provisioning:write |
Read the organization profile (get_company_info, which letterstory whoami uses) | provisioning:read |
| Read Search Console performance | insight:read |
| Publish to a connected CMS | connector:publish |
Read the webhook destination via the API (get_webhook) | webhook:read |
Set the webhook destination via the API (set_webhook) | webhook:manage |
The full list with one-line descriptions is in KB-801. The API reference at /docs shows which capability every tool needs, and KB-407 explains how the run-a-primitive scopes relate to each other.
Use the key
Send it in a header on every request:
x-integrations-key: ls_your_key
Only that header carries an API key. Authorization: Bearer … is for the sign-in tokens the CLI's browser login uses; a plain API key sent that way gets 401. The three ways in, MCP, CLI, HTTP, are in the next three articles.
Webhooks
Press Webhook on a key in Settings → API Keys to receive events such as article.published and article.finished by HTTP POST. The full event list and payloads are at /docs/webhooks. This is a UI action authenticated as you, the org member, not the key itself, so no capability is required and it works on any key, revoked keys excepted.
The same webhook destination is also readable over the API with get_webhook (needs webhook:read) and settable with set_webhook (needs webhook:manage).
Rotate or revoke
Back on Settings → API Keys, each key can be revoked (it stops working but stays listed as a record) or deleted (removed for good). To change a key's name or capabilities, revoke it and create a new one. Revoking is immediate: the next request with that key gets 401. Because you made one key per integration, revoking one never breaks another.