Implementation status
Directive §188: a feature is implemented, feature-flagged or not implemented, and the documentation says which. This page covers the API and module surface: which endpoints exist, which modules are wired, which are partial.
The behavioural gaps live on their own page
The things that look finished and are not — SIP media handoff, speech-to-speech, post-call analysis, provider verification, recording consent, assistant hooks, Stripe — are on What is not built, with the code behind each claim. Read that one first if you are deciding whether to build against a feature.
Checked against the repository — the route table, the service classes, the seeded feature flags — at the time of writing. If you find it disagreeing with the code, the page is the bug.
Legend
| Meaning | |
|---|---|
| works | Implemented and reachable through the documented interface. |
| flagged | Implemented behind a per-organization feature flag. |
| partial | Some of it works; the row says which part does not. |
| not built | Specified only. Do not plan around it. |
The REST API
305 operations across 221 paths under /api/v1, all authenticated by API key, all tenant-scoped from the key. Verified with php artisan route:list --path=api/v1 and against docs/api/openapi.json, which callagent:openapi:export --check keeps honest.
| Domain | Operations | |
|---|---|---|
| Assistants + versions | 14 | works |
| Structured outputs | 7 | works |
| Tools + versions | 11 | works |
| Squads | 9 | works |
| Knowledge bases + documents | 11 | works |
| MCP servers | 10 | works |
| Calls, transcripts, events, metrics, costs, artifacts | 16 | works |
| Telephony: numbers, accounts, trunks, gateways, DIDs, routes, outbound | 47 | works |
| Contact centre: queues, operators, supervisor, transfers, extensions, catalogue | 60 | works |
| Campaigns + suppression lists | 24 | works |
| Analytics, boards, monitors, evals, simulations, issues | 31 | works |
| Billing: balance, ledger, usage, credits, invoices, payment methods, plans | 17 | works |
| Webhooks + delivery log | 11 | works |
| Platform: api-keys, client-tokens, customers, integrations, credentials, registry | 41 | works |
Two earlier claims corrected
Previous versions of this page said campaigns and the contact centre had no REST endpoints. They do — 24 and 60 respectively — and the pages have been rewritten.
Endpoints that do not exist
| Expected | Reality |
|---|---|
POST /api/v1/client/calls | not built Starting a browser call through the API. The token exchange (POST /client-tokens) is live; this is not. |
/api/v1/policies | not built The CLI validates policies/ locally and says it cannot push them. |
/api/v1/files, /api/v1/storage | not built Storage destinations are configured in the dashboard only. The storage.write scope exists with nothing behind it. |
/api/v1/chat | not built A ChatController exists in the tree but no route file references it. The chat.read / chat.write scopes are unreachable. |
/api/v1/sms | not built The sms tool type and the send contract exist; there is no REST endpoint. |
Endpoints outside /api/v1
| Path | |
|---|---|
GET /api/health, /api/health/ready | works unauthenticated by design |
POST /mcp | works CallAgent as an MCP server — API-key authenticated |
/api/internal/v1/* | works gateway-only, separate auth |
/scim/v2/* | partial user provisioning only; group provisioning is absent |
/telephony/*, /webhooks/billing/stripe | works provider callbacks |
Things that are built but not wired up
The most important section on this page. Each of these has complete-looking code that nothing calls, so the feature does not happen at run time.
| Feature | State |
|---|---|
| Post-call analysis — summary, sentiment, topics, success evaluation | not built The pipeline and its job class exist, and the finaliser runs redaction, artifacts, transcription and retention — but never dispatches the analysis job, and there is no test covering it. calls.summary is populated only if the gateway supplies it in the finalisation payload. See Analytics. |
| Speech to speech | not built speech_to_speech_model is validated, stored, versioned, published and shipped to the gateway. The live call session never reads it. A complete S2sPipeline exists and nothing constructs one. Detail. |
| SIP trunk media | not built Trunk registration, IP authentication and ACL admission are proven against a real SIP peer. The handoff of media from FreeSWITCH to the gateway is not built, so no trunk call has ever reached an assistant. Detail. |
| Assistant hooks | partial Fourteen triggers are declared, converted and shipped to the gateway. The gateway source contains no reference to hooks. Only handoff runs, in the control plane. Detail. |
| Five tool types | not built bash, computer, text_editor, client_side and custom_provider have no entry in the wire-format mapping and are silently dropped from every call. Detail. |
| Structured output extraction | not built Same cause: definitions, versioning and storage all work; the extraction is performed by the analysis pipeline above. See Structured outputs. |
| Scorecards on live calls | partial The scoring engine is real and is exercised by simulations. Scoring a live call depends on the analysis pipeline. |
| Observability trace export (Langfuse, OTLP) | not built Exporters exist; nothing invokes them. The gateway logs it plainly: "tags and sampling are applied, spans are not shipped." Do not plan an integration on it. |
Partial implementations
| Feature | What works, what does not |
|---|---|
| Post-call transcription | partial The provider list comes from the registry, but Sonix is the only adapter. Any other choice has no client behind it, and the UI says so rather than failing later. |
| Knowledge vector stores | partial pgvector and custom are implemented. Qdrant, Pinecone and Weaviate exist as enum cases so the interface can say "not yet" honestly. |
| Embeddings | partial OpenAI is the only embedding provider implemented. |
| Browser session protocol | partial Audio and barge-in work end to end. The conversation events (transcript, message, state, tool_call, ended …) are still landing on the gateway. See The browser. |
| Per-carrier telephony capabilities | partial Each provider declares its own capability matrix — Twilio marks SIP trunking partial, the custom SIP provider marks number listing partial, DIDWW declares three capabilities. Read the matrix, not the provider name. |
| SCIM | partial Users provision; groups do not. |
| Integrations catalogue | partial The gallery only shows connectors whose maturity is implemented; the rest are registered as not-implemented and hidden. |
Not implemented
| Feature | Note |
|---|---|
Operator web phone (module.web_phone) | Architecture settled — reuses the Web SDK's WebRTC transport. Not built. Operators register a SIP device. |
| SAML SSO | The SSO service returns "SAML is not implemented in this build" and there is deliberately no route. Blocked on an XML-DSig library. |
| SCIM group provisioning | See above. |
| SMS | Contract and tool type exist; no endpoint, no adapter. |
| Chat channel | Controller exists, unrouted. |
Implemented
| Feature | Note |
|---|---|
| OIDC SSO | works |
| Webhooks | works The one module the flag ledger marks implemented. Signing, rotation overlap, at-least-once delivery with a stable event id, scheduled retry, delivery log, redelivery. |
| API keys | works Hashed private keys, one-time reveal, scopes, origins, assistant and IP restrictions, rotation with overlap. |
| Customer-owned storage | works S3, R2, Azure Blob, S3-compatible, platform. Real write/read/delete validation; per-artifact custody; relocation job. |
| Dual-channel recording | works Plumbed to the carrier — Twilio RecordingChannels, FreeSWITCH record_stereo. |
| Recording consent | partial An announcement can be played and the state is recorded. Recording starts before the announcement is spoken, and the gateway can only ever report announced — never granted or denied, because nothing collects an acknowledgement. A refusal cannot be honoured. Detail. |
| AI disclosure (EU AI Act Article 50) | not built compliance_plan reaches the gateway and is never read. Nothing makes an assistant say it is an AI. Put it in first_message yourself — see AI disclosure & consent. |
| Provider adapters | partial verified means the wire format was reviewed against vendor documentation. No adapter has been run against a live vendor in CI. 19 voice ids, 16 adapters, 2 flagged verified. Detail. |
| Telephony carriers | partial Nine ids, six adapters, and only Twilio has a working media path to the AI pipeline. Telnyx declares media_streams and has no media-stream builder. Matrix. |
| Cost accounting | works …and honest: an unverified price produces a row with cost = 0 and priced: false rather than a guess. |
| Analytics store | works Materialised rollups plus a raw path for percentiles, funnels and cross-dimension filters. Real percentile_cont. |
| Monitors and issues | works Evaluated every five minutes. |
| Provider workbench | works …with figures marked: latency is the vendor's published typical, quality is an editorial index, cost is derived. See Providers. |
| Audit log | works Insert-only, with an exclusion list so credentials are never written down. |
| Multi-tenancy | works Global scope plus an explicit context holder; the trait throws rather than writing a row with no organization. |
About the feature-flag ledger
FeatureFlagSeeder records a maturity for each module and is the closest thing to an official list. Treat it as documentation of intent, not as an enforced switch — nothing outside the flag resource itself reads the table to gate navigation. It is also behind reality in places: module.mcp_server, module.web_sdk and module.cli are all seeded not_implemented and all three are built.
Blocked on credentials, not code
Complete in code, waiting only on accounts:
- A Twilio account, a purchased number and a public tunnel URL — live PSTN calls.
- Deepgram / OpenAI / ElevenLabs keys — real provider latency measurement.
- Stripe test keys — the pay-as-you-go purchase flow. Stripe has never been contacted at all, live or test: every Stripe test drives the real SDK against canned fixtures.
- A SIP trunk or a test PBX — the SIP acceptance path.
- A Sonix account — post-call transcription.
This documentation set
| Piece | How it is produced |
|---|---|
| Guides, concepts and platform pages | Written by hand, against the code. |
| API reference | Generated from docs/api/openapi.json by scripts/generate-api-reference.mjs. 305 operations, 39 resources, 63 schemas. |
| Schemas | Generated from the same document. |
| CLI reference | Generated from the command manifest the binary is built from. |
| SDK types | Generated from apps/web-sdk/src with TypeDoc. |
| Error codes · Event types | Transcribed from @callagent/contracts, which is mirrored in PHP with a drift test. |