ZazaVoice/Docs
PricingDashboard

Capabilities & limits

Honest scope of what the ZazaVoice API does today, and what's not yet exposed programmatically. Builds on us shouldn't be surprised by what they can or can't automate.

What you can do via API today

  • Dispatch outbound calls — POST /v1/calls/outbound with a from number, to number, and agent ID. The AI runs the conversation; the result lands as a call.completed (or call.failed) webhook.
  • List + read call history — GET /v1/calls (paginated, filterable by direction / status / agent / date range) and GET /v1/calls/{id} (single call + transcript turns).
  • List + read voice agents — GET /v1/agents, GET /v1/agents/{id}.
  • List + read campaigns — GET /v1/campaigns, GET /v1/campaigns/{id}.
  • Receive outbound webhooks for call.started, call.completed, call.failed, campaign.lead.updated, sms.received, and appointment.created.

That's the supported integration shape today — dispatch + read + listen.

What's not in the API yet

These are real boundaries; if your product needs them, factor that into your roadmap or reach out about timelines.

  • ❌ Send SMS programmatically. SmsService.send is internal-only — one-off SMS and broadcasts work through the dashboard UI today. The /v1 API doesn't expose an SMS send endpoint yet.
  • ❌ Create / update / delete voice agents. Agents are read-only via API. You create and edit them in the dashboard. (Use case: you want to spin up an agent per customer onboarding via API — not yet supported.)
  • ❌ Create / control campaigns. No POST /v1/campaigns, no API endpoints to add leads, start, pause, restart. Campaigns are dashboard- driven.
  • ❌ Manage phone numbers. No marketplace search or purchase API; no release API; no connect-to-agent API. All number management is dashboard.
  • ❌ Manage webhook endpoints. Configured via dashboard, not API.
  • ❌ Per-call recording control. Recordings follow the agent's recording-consent setting; no per-call override via API.

These will likely become public API endpoints over time — they exist internally and are exercised by our own dashboard. They're just not stable enough for external callers to depend on yet.

What white-label-style resellers should know

If you're building a customer-facing product on top of ZazaVoice:

  • One ZazaVoice org = your whole account. There's no built-in sub-tenancy where your customers are nested orgs under yours. You hold the API keys, the numbers, the agents, the billing relationship — and you decide how to multiplex your own customers on top.
  • Common pattern: model your customers in your own DB; map each to one of your voice agents (or share agents and pass per-customer context through your system prompt + dynamic data). Dispatch calls via API as the right agent. Aggregate the resulting webhooks back to the right customer in your DB.
  • No custom domain per reseller yet. Your end-customers don't see ZazaVoice URLs because everything happens server-to-server (your product → our API → carrier). The ZazaVoice dashboard is your internal-ops tool, not exposed to your customers.
  • Billing is between you and ZazaVoice. Your customers pay you; you pay ZazaVoice for the underlying usage. Top up a PAYG wallet or run a subscription, then mark up however you like in your own product. We don't have a wholesale price tier today — same per-minute / per-SMS / per-number pricing as our direct customers — so margin sits in your pricing layer.
  • Compliance is shared. Recording disclosure, TCPA hours, SMS opt-out, 10DLC registration — these need to be handled correctly for your end-users. The platform enforces the technical defaults (opt-out list, TCPA hours per campaign, recording-disclosure text per agent); your business is responsible for the policy choices.

Rate limits & idempotency

  • A per-key rate limit applies. Defaults are generous; if you hit 429, back off and retry. We'll document the exact limit once it stabilizes.
  • The API is not yet idempotency-key aware. If a POST /v1/calls/outbound times out before you got a response, the call may have been queued — check GET /v1/calls?… to confirm before retrying. Idempotency-Key header support is planned.

Versioning

The current API version is /v1. Additive changes (new fields, new endpoints) ship under /v1. Breaking changes will get a new prefix (/v2); we'll keep /v1 running for at least 12 months after a deprecation announcement.

Where to go next