Roadmap

Assume nothing here is served unless the entry says shipped or live

This page is the register of designed-but-unbuilt surfaces, kept so a design is never confused with the live API. If an entry is not explicitly marked shipped or live, the current core does not serve it — do not build against it yet. Entries that were designed here and delivered afterwards stay on the page, marked and linked to their reference, so the record of what was promised and what landed is one page. The implemented surface is exactly what REST API and WebSocket events describe.

Outbound webhooks

Server-to-server push of platform facts to your endpoints — built in core (MT-CTI-04, phases 1-4): the endpoint registry /v1/webhooks, an outbox written in the same transaction as the fact, a dispatcher with HMAC signatures, a capped retry ladder and an append-only delivery log. The integration guide is Outbound webhooks (CRM integration).

It is not yet in a published core release, so it is absent from the vendored spec this site generates its API Reference from — the guide says so at the top, and the reference becomes the authority on request and response shapes once a release carries it. This entry stays until then.

Not to be confused with the inbound SMS webhooks, which are live: the platform hosts signed endpoints that SMS providers call with delivery receipts and consumer replies — see Webhooks in the API Reference.

What the design preview on this page promised, and what was actually built — the record of both, since that is what this page is for:

Promised here	Built
Payloads: dialer.v1 messages as protojson (CallEvent, CallDetailRecord, ComplianceDecision)	A v1 envelope {event, event_id, occurred_at, tenant_id, data} whose data is the public /v1 projection of the resource — the same shape its GET answers, not protojson. Compliance decisions are not an event; the six-name catalog is call.ended, call.answered, promise.recorded, sms.received, sms.optout, recording.available.
Routing header X-DD-Event-Type	X-DD-Event
Unique X-DD-Delivery-ID	X-DD-Delivery-Id — the receiver's idempotency key, as promised
X-DD-Signature: t=<unix>,v1=<hex> over "<t>.<raw body>", constant-time, ~5-minute tolerance	As promised, plus X-DD-Signature-Previous during a 24 h rotation window
Respond 2xx within 10 s	15 s for the whole request, 5 s of it for the connect
Retries with exponential backoff; at-least-once; no cross-delivery ordering	As promised. The ladder is capped and bounded by a maximum attempt count, then dead-letters; dedupe is on X-DD-Delivery-Id (delivery) and event_id (fact), not on callId/decisionId.
Self-service endpoint CRUD + delivery log per tenant	As promised: CRUD, secret rotation, GET /v1/webhooks/{id}/deliveries with every attempt, and a manual redelivery that appends.

Protojson alignment

The contracts repo defines dialer.v1 (see Contracts), but the REST API currently speaks its own snake_case JSON with lowercase dispositions (answered_human, …), not protojson with enum names (DISPOSITION_ANSWERED_HUMAN). Pending alignment work:

• GET /v1/reports/cdr returning verbatim dialer.v1.CallDetailRecord protojson — today the CDR surface is /v1/call_attempts over the durable call_attempts table.
• A GET /v1/dispositions catalog derived from the dialer.v1.Disposition enum.
• Mapping the engine's lowercase dispositions onto the Protobuf enum naming without inventing a third shape.

Compliance reporting endpoints

• Durable blocked-dial reporting shipped under different paths: GET /v1/stats/blocked (by-gate counts + daily series over the append-only gate_blocks evidence) and the packaged GET /v1/reports/violations-prevented (JSON/CSV). The proposed GET /v1/reports/compliance/blocked name is superseded by these.
• GET /v1/consumers/{id} (debtor card + pre-digested compliance read model) is not implemented; the per-debt view is GET /v1/debts/{id}, and the sealed GET /v1/debts/{id}/defense-packet is the litigation bundle.

User accounts, roles, SSO, MFA

• Dashboard user accounts — shipped: email + password login minting a revocable ddu_ session, logout, password reset, and user management (create, disable, re-enable — rows are audit evidence and never delete). Machine-to-machine callers still use per-tenant API keys, and there is no X-Tenant-ID impersonation.
• Roles — shipped, but deliberately small: a two-value role on each user (member / account_admin). Only an account_admin may write the empresa-wide rows sibling sedes inherit; a member gets 403. The role is read-only over the API — promotion is an operator gesture, not a request. There is no general role/permission system.
• SSO (SAML) and MFA — not implemented. The dashboard's affordances for both render as pending; no endpoint mints or verifies a second factor, and no assertion consumer exists.

Agent workspace surfaces

• GET /v1/agent/queue (per-agent queue view) — not implemented.
• PATCH /v1/agents/{id}/status — not implemented; presence changes only via checkin/checkout and the dialer itself.
• A wrap_up presence state — does not exist yet (live states: offline|available|ringing|on_call).

Telephony control & AMD

• Supervisor audio (listen / whisper / barge / take-over) — shipped (telephony control v0.4): the supervision endpoints are live, the Live Monitor drives them, and supervision.started/ended stream on the live floor.
• AMD (answering-machine detection) — no verdicts anywhere yet. The amd_verdicts rewind filter is reserved and returns 422 fail-closed rather than being silently ignored.
• Recordings retrieval API — shipped: listing, per-recording fetch, signed playback URLs and legal hold are live.
• Per-day schedule grid for campaigns — pending.

Import & data plumbing

• CSV multipart upload for /v1/debts/import — JSON-only today (the dashboard's CSV mapper converts client-side).
• Server-side mapping templates for the CSV mapper (currently browser localStorage).
• Per-key request quotas on /v1 — not implemented. What exists today: dial/SMS rate brakes and monthly spend caps (429 throttled / 429 sms_spend_cap_exceeded), documented in Rate limits & caps. No Retry-After header yet.

Channels

SMS is live: gated one-off sends, a unified ledger, per-region provider routing and signed provider webhooks — see the SMS reference and Webhooks. WhatsApp is not built. Voice and SMS are the only channels core serves today.