Skip to main content

​
API keys

All Sendora API requests authenticate with an API key passed in the X-API-Key request header.

​
Key formats

Use a deliberately limited workspace and non-destructive requests for development. A test-prefixed key is not a substitute for a separately isolated sandbox.

​
Creating a key

  1. Log in to app.sendora.ai
  2. Go to Settings → API Keys
  3. Click Generate new key
  4. Give it a descriptive label (e.g., zapier-integration, n8n-production)
  5. Copy it immediately, it is shown only once
Each key records the workspace role of the person who created it and shows it in the key list; keys created earlier show no creator and work exactly as before. Only managers, admins and owners can create API keys, and every request is checked against the creator’s current role.
Store API keys in environment variables or a secrets manager. Never hardcode them in source code or commit them to git.

​
Rotating a key

  1. Generate a new key
  2. Update your integration to use the new key
  3. Delete the old key from Settings → API Keys
There is no forced rotation schedule, but rotating keys every 90 days is recommended.

​
Permissions, scopes, role and plan

A key authenticates one workspace. What it may do is the combination of four checks, applied on every request: Keys are created with read, write, all or *. Any other scope is rejected with 422 when the key is created.
A key follows its creator’s current access. If the person who created it is removed or suspended, the key stops working (403); if their role is reduced, the key loses whatever the new role cannot do. Keys created before creators were recorded show no creator and act as workspace-level service identities, so delete or replace them when people leave. Issue the narrowest scope that works (read for reporting) and keep one key per integration.

​
Your Sendora key is not your AI-provider key

There are two separate credentials, and they are never interchangeable: You never send a provider key to the API, and the API never returns one. Sendora resolves the provider and model for each workspace on the server, from the campaign’s own AI configuration first and the workspace default after that. If your own key is missing or fails, AI steps fall back to the platform default and are billed as documented for your plan; the API does not accept a provider key or model credential in a request to override this. Connected AI assistants (the workspace MCP) sign in with OAuth, not with an API key.

​
Credits and usage

Requests that run a billable action (AI steps, messages, calls, enrichment) are charged to the workspace that owns the key, using the same rates as the app. A GET never spends credits. When a write may be retried, send an Idempotency-Key so a retry cannot repeat the action (see Idempotency). The usage shown in the app is the source of truth for what was charged; do not infer charges from an HTTP 200 alone.

​
Security checklist

  • Keys stored in environment variables, not source code
  • A deliberately limited workspace is used for non-production testing
  • One key per integration (easier to rotate without affecting others)
  • Old / unused keys deleted from the dashboard
  • Webhook signatures verified on every inbound event (see Webhooks)

​
Error responses

Resource ownership failures are intentionally reported as 404 Not Found so a key cannot use the API to discover another workspace’s resource IDs. 403 is reserved for entitlement and widget-origin policy failures.