Documentation
Docs
How to get your inbound calls transcribed and scored, and the shape of the REST API and MCP server we are building. Anything marked in build is not live yet. We would rather show you the design now than publish a reference that does not answer.
The full reference lands with the endpoints, not before it. Dated shipping notes go in the changelog.
Three steps to a labelled call
No setup fee and no implementation project. If your calls already sit in a call platform, the work is a credential and a date range. Nobody has to change how the phones ring.
Read the status labels literally. The Ringba connector is in build, not self-serve: it works, but today we connect it with you rather than from a settings page, so step 02 below is how it will work when it lands. Per-connector status is on integrations, and everything that ships is dated in the changelog.
Create a workspace
Sign up and name the workspace. A workspace is the isolation boundary: its calls, keys, connections and seats never cross into another one. Multi-location businesses and agencies run one workspace per book of business.
Connect a source
Add your call platform credentials and pick a backfill window. We read calls, numbers, sources, revenue fields and recording URLs. We do not route calls or change how your phones ring — the platform stays the system of record. See integrations.
Analyze calls
Analysis transcribes each recording and attaches what the caller wanted, an outcome, an intent score, an estimated value and spam/voicemail flags. Every label points at the part of the transcript that produced it. Syncing is free; analysis draws down your monthly credits.
Set your workspace timezone first
Every aggregate — daily call counts, month-to-date revenue, hour-of-day breakdowns — is computed in the workspace timezone, and month boundaries follow it. Setting it before the first backfill saves you reconciling a month that started in the wrong hour. The full counting rules are on how we count.
Versioned, org-scoped, cursor-paginated
The API will be included on Scale and Agency, and will expose the same data the dashboard reads: calls with their labels, transcripts, what callers asked for, and revenue aggregates. Design decisions are settled; the endpoints are not open yet, on any tier.
| Design decision | Shape |
|---|---|
| Versioning | Every path is prefixed /v1. Breaking changes ship as a new prefix, never as a silent field change inside one. |
| Authentication | Bearer keys, scoped to one workspace. A key issued in one workspace cannot read another, including inside an agency account. |
| Scopes | Per-key scopes such as calls:read, demand:read, revenue:read, labels:write (for correcting a label a human disagrees with). Keys are individually revocable and show last-used time. |
| Pagination | Cursor-based. Responses carry next_cursor; offsets are not supported, because call rows keep arriving underneath a paging read. |
| Rate limits | Per key, per minute, with remaining budget and reset returned in response headers. The exact ceilings get published here when the API opens — quoting a number for an endpoint you cannot call yet would be worthless. |
| Errors | Conventional status codes with a machine-readable code and a human message. No 200-with-an-error-body. |
curl -sS "$API_BASE/v1/calls?from=2026-07-01&to=2026-07-31&limit=100" \
-H "Authorization: Bearer $API_KEY" \
-H "Accept: application/json"
# response (abridged, illustrative values)
{
"data": [
{
"id": "call_01H...",
"started_at": "2026-07-14T15:22:08Z",
"duration_sec": 214,
"caller": { "number": "+1555...", "area": "Denver, CO", "first_time": true },
"source": "google-organic",
"location": "north-branch",
"answered_by": "member_14",
"revenue": 480.00,
"is_duplicate": false,
"labels": {
"outcome": "booked",
"intent_score": 0.86,
"requested_service": "emergency drain clearing",
"estimated_value": [1800, 3200],
"questions_asked": [
"Do you cover Saturday call-outs?",
"Is the call-out fee refunded if I book?"
],
"unanswered_questions": ["Do you cover Saturday call-outs?"],
"spam": false,
"voicemail": false
},
"evidence": { "requested_service": { "start_ms": 8400, "end_ms": 15200 } }
}
],
"next_cursor": "eyJvIjoxMDB9"
}
Values above are made up to show the response shape. They are not sample output from a real account, and the caller in them does not exist. Two of the label fields — questions_asked and unanswered_questions — depend on the team-performance work that is still in build, so they will arrive after the analysis fields do.
Ask your calls what happened
A read-only Model Context Protocol server over streamable HTTP, so that an MCP client will be able to query your labelled calls, transcripts, what callers asked for and revenue aggregates directly — "what did people ask about most last week", without opening a chart. It is being built to the MCP spec, so any compliant client will be able to connect; Claude Desktop, Claude Code and Cursor are the ones we are building against. Nothing here answers yet.
Read-only by design
The server will only ever query your workspace. It will not be able to change a label, edit a call or write anything back to your call platform. That constraint is structural, not a setting.
Scoped to one workspace
It will authenticate with the same workspace-scoped keys as the REST API, so an MCP session inherits exactly the access that key has and nothing else.
Not a first
Read-only MCP servers already exist in analytics and adtech — Everflow ships one and Triple Whale ships a Claude connector. Ours is scoped to your own call data. We are not claiming a category first.
{
"mcpServers": {
"calls": {
"type": "http",
"url": "$MCP_BASE/mcp",
"headers": {
"Authorization": "Bearer $API_KEY"
}
}
}
}
$MCP_BASE and $API_KEY are placeholders. The real values, the tool list and the client-by-client setup notes get published here when the server opens.
What is not here yet
No endpoint reference, no SDKs, no webhook catalogue, no OpenAPI file. They arrive with the API rather than ahead of it. Two things you can rely on in the meantime: full CSV export on every tier, and a dated public record of everything that ships.
Need something specific before it ships?
If a particular endpoint, field or MCP tool is what would make this useful to you, say which one. That is how the build order gets set.