Skip to content
Zumu
Demo

Platform API

On most call center platforms, the API is an afterthought bolted onto the dashboard. On Zumu, the dashboard is a client of the API.

A versioned REST surface over agents, calls, numbers, and knowledge, returning the same session data your dashboard renders: cost by component, which provider served the call, and the full tool trace.

  • Versioned at /v1
  • OpenAPI + interactive reference
  • Org-scoped keys with scopes
  • Same data your dashboard renders
Book a demoSee a real request

One request, the full session

What comes back is what the dashboard already knows

A single call, requested by id. The response is shaped like the session report a supervisor reads in the Conversation Pod: cost by component, which provider served the call, why a transfer fired, and the tool trace. No mockup fields.

session.sh
$ curl https://agents.zumu.ai/v1/calls/call_8f2b1e1c \
  -H "Authorization: Bearer zumu_sk_••••••••3f2a"
{
  "id": "call_8f2b1e1c",
  "agent_id": "agt_419e2a",
  "direction": "inbound",
  "status": "completed",
  "outcome": "resolved",
  "started_at": "2026-07-30T14:02:07Z",
  "ended_at": "2026-07-30T14:16:41Z",
  "queue": {
    "caller_joined_at": "2026-07-30T14:02:07Z",
    "agent_first_audio_at": "2026-07-30T14:02:11Z",
    "abandoned_pre_agent": false
  },
  "provider": {
    "llm": "openai",
    "stt": "deepgram",
    "tts": "elevenlabs"
  },
  "transfer": {
    "occurred": true,
    "method": "warm",
    "reason_code": "customer_requested_human"
  },
  "cost": {
    "currency": "usd",
    "billed_party": "ai_agent_seconds",
    "components": ["voice_agent", "noise_cancellation", "observability", "recording"]
  },
  "tool_trace": [
    { "tool": "search_knowledge_base", "status": "ok" },
    { "tool": "update_appointment", "status": "ok" }
  ],
  "recording_url": "https://agents.zumu.ai/v1/calls/call_8f2b1e1c/recording",
  "transcript_url": "https://agents.zumu.ai/v1/calls/call_8f2b1e1c/transcript"
}
Every field above is a real column in the session report: cost broken out by component, which provider actually served the call, the reason a transfer fired, and the full tool-call trace. Durations and dollar amounts are left out here on purpose; the shape is real, the numbers on this page are not.

The resource areas

Four areas, one concrete thing each

Not an exhaustive endpoint list. One real capability per area, traced to what the product actually stores and serves.

  • AGENTS

    PATCH /v1/agents/{id}

    Read a full agent configuration, or push a new one

    Every call fetches its prompt, voice, model, tools, knowledge, and telephony policy fresh from the database, so a change made through the API is live on the next call. Nothing to redeploy.

    Changes are versioned. The same surface that reads a configuration can also read its revision history or restore an earlier one.

  • CALLS

    GET /v1/calls/{id}

    Pull the full session report for any call

    The payload behind a Conversation Pod, including the tool-call trace, the transfer record, and the recording, is the same payload the API returns.

    Bulk export and active-call status live on the same surface, so a script can watch what a supervisor watches.

  • NUMBERS

    GET /v1/numbers

    Manage telephony the way the dashboard does

    Phone numbers, SIP extensions, and call-flow configuration are part of the same platform your agents already read from at call time, whether the number is Zumu-provisioned or a SIP trunk you brought yourself.

    A number reassigned through the API is live on the next call. There is no separate publish step.

  • KNOWLEDGE

    POST /v1/retrieve

    Query retrieval before it ever reaches a caller

    The same hybrid graph-and-vector retrieval an agent calls mid-call is available directly, so you can test what a query surfaces or wire your own tooling to the same knowledge base.

    Knowledge Units, not a flat vector index: the graph an agent queries is the output of an eight-stage pipeline, and the API reads that output.

How it behaves

Auth, versioning, and the docs

Scoped to your organization
Every key is issued for one organization and can carry scopes, so a key wired into a reporting tool can be read-only while one in your deploy pipeline manages agents.
Versioned at /v1
Routes live under one version prefix, so the surface can grow without moving the ground under an integration you already shipped.
Self-documenting
The full surface is published as an OpenAPI document, with an interactive reference beside it, so a field is never something you have to discover by trial and error.

Where this fits

The API is not the only way in

Questions

What engineers ask before they wire this up

Still have questions?

Bring a real integration question. We will look at it with you, live.

Book a demoTalk to sales
It covers the ground that matters for building on Zumu rather than clicking through it: agents (configuration, settings, revisions), calls (payload, tool trace, transfer record, export), analytics, knowledge retrieval, transfers, recordings and tags, and the MCP surface. It is versioned REST, the same surface the dashboard itself calls.

Bring your own script

Point a request at a real call. We will walk the response with you.

Bring a call from your own org, or one of ours, and we will go through the fields together: what is live today, and where MCP or a webhook might fit better than another poll.

Book a demoTalk to sales
  • One key across environments
  • Scoped by organization
  • OpenAPI + interactive reference
Call Center API | Voice AI API for Agents, Calls & Knowledge | Zumu