KaiCalls Has a Developer Platform: An API for a Phone System That Captures and Qualifies Calls
Scoped API keys, communication runs, filtered webhooks, and durable events with replay. Here is what the KaiCalls developer platform gives integrators and agencies.
Use the KaiCalls developer platform to mint scoped API keys, launch communication runs, and subscribe to durable webhooks, so your software can drive a phone system that captures and qualifies calls. The platform exposes a public /v1 API, filtered webhook subscriptions, and an event store with replay, so an integrator builds on KaiCalls the way they would build on any modern API.
KaiCalls started as a secretary you talk to. Now it is also a system you can build on. Agencies, vertical software vendors, and partners can wire KaiCalls into their own product instead of treating it as a closed dashboard.
This guide walks through what the developer platform exposes, how the pieces fit, and where to start. You get API keys, communication runs, webhooks, and a durable event surface, all documented with an OpenAPI spec.
Where the developer platform lives
The developer platform sits in your dashboard at /dashboard/settings/api-keys. That page is where you mint and manage API keys for your workspace. The API docs live at /docs/api, and a runnable quickstart lives at /docs/api/quickstart.
A KaiCalls workspace already captures calls, qualifies callers, books appointments, and follows up by text and email. The developer platform turns those capabilities into endpoints. Your software reads the same leads and calls the dashboard shows, and your software triggers the same outbound communication the secretary can.
The whole surface is described by an OpenAPI spec. You point your client generator at the spec, and you get typed methods for every public route without reading the docs line by line.
Scoped API keys
API keys on the platform are scoped rather than all-powerful. A scope limits what a key can read and write, so a key handed to one integration cannot quietly reach the rest of your workspace.
Scoping matters most for partners. An agency embedding KaiCalls for a client can issue a key limited to that client's data and that integration's actions. The key does what the integration needs and nothing else.
Scoped keys are the foundation the rest of the platform sits on. Every call to the /v1 API carries a key, and the scope on that key decides what the call is allowed to do.
Communication runs
A communication run is how the API launches outbound contact. The run model covers the full lifecycle, so your software validates a run, previews it, creates it, then pauses or cancels it if plans change.
The lifecycle endpoints are explicit:
- Validate a run with
POST /v1/communication-runs/validatebefore you commit anything. The validate step checks the run is well formed so you catch problems before they reach a customer. - Preview the run to see what it will do once it executes.
- Create the run to launch it for real.
- Pause or cancel the run if you need to stop it mid-flight.
Create calls require an Idempotency-Key. The idempotency requirement means a retried request never launches the same run twice, so a flaky network or a double-click in your own app does not double-contact a customer. This is the standard pattern modern payment and messaging APIs use, and the KaiCalls API enforces it on run creation.
Filtered webhooks
Webhooks push events to your endpoint instead of making you poll. The KaiCalls platform supports subscription webhooks with three features that make them safe to run in production.
The first is event filtering. You subscribe to the specific events you care about, such as a call starting or an SMS being delivered, so your endpoint only hears what it needs. The expanded event surface covers call.started, voicemail.received, and sms.sent, sms.delivered, and sms.failed, alongside the rest of the documented set.
The second is test delivery. You fire a test event at your endpoint while you build, so you confirm your handler works before a real event depends on it.
The third is secret rotation. You rotate the signing secret on a subscription without tearing it down, so you keep your verification current without dropping live deliveries.
Durable events with replay and backfill
Webhooks fail. Endpoints go down, deploys drop in-flight requests, and networks time out. A push-only system loses those events for good. The KaiCalls platform stores events durably instead.
Every event is recorded with its delivery attempts, so you can see what was sent and whether it landed. Three endpoints turn that store into a recovery tool:
- List events through
/v1/eventsto read the durable record of what happened in your workspace. - Inspect deliveries through the event-deliveries surface to see each attempt against your endpoint.
- Replay or backfill events when your endpoint missed them, so a downtime window becomes a catch-up job instead of a permanent gap.
Durable events change how you build. You stop treating a missed webhook as lost data, because the event is still in the store and you can replay it once your endpoint recovers.
Evidence read APIs
The platform also exposes read APIs for the records behind a call. These are the evidence endpoints, and they let your software pull the artifacts a call produced.
The evidence surface covers SMS messages and conversations, jobs, attempts, and recordings. An integration that needs to show a client what happened on a call reads these endpoints instead of scraping the dashboard. The agent config versions read endpoint also lets you see the configuration an agent was running, so you can correlate behavior with the exact version that produced it.
Read APIs round out the platform. You launch action with communication runs, you hear about results through webhooks, and you pull the underlying records through the evidence endpoints.
Who the developer platform is for
The platform fits three audiences.
Agencies that resell or embed KaiCalls get scoped keys per client and webhooks per integration, so they manage many businesses through one API. Vertical software vendors that need call capture inside their own product get an API to wire it in, instead of asking their users to live in a second dashboard. Partners building an audit or reporting layer on top of KaiCalls get durable events and evidence reads, so their system stays in sync even through downtime.
If your software needs a phone system that captures, qualifies, and reports, the developer platform is the seam to build against.
How to start
Follow these steps to make your first authenticated call.
- Open the developer platform at
/dashboard/settings/api-keysand mint a scoped key. - Read the quickstart at
/docs/api/quickstartto make your first authenticated request. - Generate a client from the OpenAPI spec linked in the API docs so your code gets typed methods.
- Validate a communication run with
POST /v1/communication-runs/validateto confirm your payload before you launch anything live. - Subscribe a webhook to the events you care about, fire a test delivery, and confirm your handler verifies the signature.
That sequence gets you from zero to a working integration without guessing at the surface, because every route is in the OpenAPI spec and the quickstart shows the auth flow.
FAQ
Does KaiCalls have an API?
Yes. The KaiCalls developer platform exposes a public /v1 API with scoped keys, communication runs, filtered webhooks, durable events, and evidence read endpoints. You manage keys at /dashboard/settings/api-keys and read the docs at /docs/api.
How do I launch outbound contact through the API?
Use communication runs. You validate a run with POST /v1/communication-runs/validate, preview it, create it with an Idempotency-Key, and pause or cancel it if needed.
What happens if my webhook endpoint goes down?
Events are stored durably with their delivery attempts. You replay or backfill the events your endpoint missed through the /v1/events and event-deliveries surface once it recovers.
Can I limit what an API key can do? Yes. Keys are scoped, so a key issued to one integration only reads and writes what that integration needs.
Is there an OpenAPI spec? Yes. The public v1 routes are covered by an OpenAPI spec linked from the API docs, so you can generate a typed client.
Build on it. Read the quickstart at kaicalls.com, or call the KaiCalls demo line at (417) 386-2898 to hear the secretary your integration will be wiring into.
Topics:
Related Posts
Dispatcher briefings let Kai brief you on the day's calls, hot leads, and what needs a callback when you call your own number. Here is how the briefing works.
7 min readHow to Know Your AI Receptionist Is Ready Before You Forward Your LineThe Trust Window shows whether your AI receptionist is ready before you point real customers at it. Here is what it checks and how owners read it at a glance.
7 min readThree New Things KaiCalls Can Do: Outbound Calling, Automatic Review Requests, and Smarter Lead ScoringCall customers back from your business number on your cell, ask happy callers for reviews automatically, and rank leads by your goal. Three new KaiCalls features explained.
6 min read