Apifonica Support
Overview
Voicebot API 1.30.0
Section titled “Voicebot API 1.30.0”HTTP API for the Apifonica Voicebot. Manage scenarios, agents, numbers, tenants, accounts and users.
Authentication
Every request carries Authorization: Bearer <token>. The same header
accepts three credential kinds, told apart server-side:
- Session token — issued to a user by
POST /v1/auth/regular(email + password) or a magic link. Scoped to the user’s account. - Account API key — provisioned by an administrator; acts as that account.
- Tenant API key — provisioned by an administrator; acts across the tenant’s accounts.
Roles form a chain — reader → writer → account_admin → tenant_admin → superuser — granting capabilities read, write, delete,
manage:users, manage:account, manage:tenant, issue:apikey:*.
Each role inherits the ones before it.
Operating on another scope
A principal broader than a single account picks its target with the
X-Account-Sid (and, where a tenant must be named, X-Tenant-Sid)
header. A superuser MUST send it; an account-scoped principal may omit it
(if sent it must match their own, else the request is rejected with
scope_conflict). This is how a superuser creates a scenario for a
specific account, or a tenant admin manages any account it owns.
Workflows
Account user (session token; reader / writer / account_admin) — works inside one account.
POST /v1/auth/regular— log in for a session token.POST /v1/scenario,POST /v1/agent,POST /v1/number— build call flows (writer+ to mutate, reader to read).
Tenant and account provisioning (creating tenants/accounts, issuing their API keys) is performed by administrators over the internal network and is documented in the internal API reference.
Authentication
Section titled “Authentication”bearerAuth
Section titled “bearerAuth”Session token obtained from POST /v1/auth/regular.
Security scheme type: http