Authentication
Every request carries a scoped API key. Keys are minted in the app and carry only what you grant, so an agent or script can hold exactly the power its task needs and nothing more.
API keys
In the app, open Business → API & MCP, pick the scopes, and copy the key. Keys look like taka_live_... and are shown once at creation.
The header
curl https://api.taka.ai/v1/public/account \
-H "Authorization: Bearer taka_live_..."The same key and the same scopes drive both the REST API and the MCP server. REST also accepts X-API-Key: taka_live_... if a proxy eats your Authorization header; MCP reads Authorization only.
Scopes
| account:read | Business, plan, credits, connected channels. |
| content:read | Posts, variants, jobs. |
| content:write | Create and edit drafts. Implies content:read. |
| generate | AI generation and revision. Draws credits. Never implied. |
| publish | Publish, approve, and schedule. Never implied; a schedule ships the post at its slot. |
| brand:read | The brand kit. |
| brand:write | Edit the brand kit. Implies brand:read. |
| analytics:read | Performance data. |
- Write implies read on the same resource.
generateandpublishare never implied, they must be granted explicitly.- Scheduling requires
publish, because outside review mode a schedule ships the post when its slot arrives.
account:read + content:read + analytics:read) can report all day and ship nothing. Start there, widen when the task earns it.How keys are stored
Taka keeps only a hash of the key. If a key leaks, revoke it in the app and mint a new one; there is nothing to “view again” server-side.
Key management itself (create, list, rotate, revoke) is owner and admin territory and needs an app session. A key cannot mint keys, on purpose.