Authentication and API keys
Create an API key, choose its permissions and expiry, and authenticate your requests.
Every API request authenticates with a bearer token:
curl "https://europe-central2-mailingr-54736.cloudfunctions.net/api-v1/products" \
-H "Authorization: Bearer YOUR_API_KEY"The key identifies both you and your workspace — there is no separate workspace id to pass.
Create an API key
Open API keys in the dashboard
In the Zanfia dashboard, go to Integrations → API, MCP and CLI and click Create new API key.
Name it and pick an expiry
Give the key a name that identifies the integration it's for. Keys default to expiring after 365 days; you can pick a shorter window or, for long-lived server integrations, no expiry.
Grant permissions
Choose what the key may do, per resource: Read and/or Write for Products, Communities, and Pages. Grant the least access the integration needs — you can always create another key with more permissions later.
Copy the key immediately
The key is shown once, right after creation. Store it in a secret manager or environment variable — after you close the dialog it can't be read again, only revoked.
Permissions (scopes)
| Scope | Grants |
|---|---|
products:read / products:write | Products, prices, offers, order bumps, courses, media, clients, orders, stats, discounts |
communities:read / communities:write | Community channels, posts, comments, chat |
pages:read / pages:write | Custom hosted pages and the storefront main page |
A request outside the key's scopes fails with 403 and the reason insufficient-scope.
Key lifecycle
- Revoke a key any time from Integrations → API, MCP and CLI — revocation is immediate.
- Expired keys stop working automatically and show as Expired in the key list.
- Keys tagged CLI were created by
zanfia login— they're managed automatically by the CLI (re-created on each login, 90-day lifetime) and you don't need to touch them.
Treat keys like passwords
Anyone holding a key can act on your workspace within its scopes. Never commit keys to a repository or embed them in client-side code — API keys belong on servers, in CI secrets, or in your terminal environment.
Verify a key
Call the identity endpoint to confirm a key works and see which workspace it belongs to. This example shows the full range of generated client languages — the per-resource reference pages stick to cURL and JavaScript:
/workspaceAuthorization
bearerAuth API key from Dashboard → Integrations → API, MCP and CLI.
In: header
Response Body
application/json
application/json
curl -X GET "https://example.com/workspace"{ "workspaceId": "string", "workspaceName": "string", "userEmail": "string", "scopes": [ "string" ]}{ "error": "string"}Member keys (Community API)
Your community members can create their own, member-scoped keys from the community platform (Settings → Developer in the member portal). Member keys only work against the Community API and act as that member — they can't touch workspace resources. This is how members connect AI assistants to communities they belong to.
Was this article helpful?