Skip to main content
Audact
See the offer

Hand the conversation over. Keep the chain.

Public API host: In development

POST https://api.audact.ai/v1/continuity/handoff

The public API host. The code examples document the intended interface and the endpoints used within the current product.

No public API is served on this host yet, apart from the published Merkle roots at /v1/metachain. The endpoints used inside the product are not the same thing as a public API.

Why this status
Claim
In development · By application
Scope
The public API host. The code examples document the intended interface and the endpoints used within the current product.
Ground
No public API is served on this host yet, apart from the published Merkle roots at /v1/metachain. The endpoints used inside the product are not the same thing as a public API.
What it does not establish
That any individual endpoint works today. That is confirmed per endpoint, and the confirmation is open.
What you can get today
Production access sits inside an applicable paid agreement. Endpoints are not priced separately.
Last checked
5 October 2026
Where to check it
/apis

In controlled testing · chat and email planned

A hand-off is a compliance event, not a routing detail. Move a conversation to another channel and the disclosure duty starts again, the consent you hold may not cover the new channel, and the record splits in two. This endpoint carries the context across: the new session links back to the previous receipt, both trace to the same root, and it tells you whether a fresh disclosure is required on the channel you are moving to.

POST /v1/continuity/handoff

curl -X POST https://api.audact.ai/v1/continuity/handoff \
  -H "Authorization: Bearer $AUDACT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "from_channel": "voice",
    "to_channel": "whatsapp",
    "session_id": "sess_8h2k9d7",
    "subject_id": "subj_3kp9zq",
    "carried_consent": ["marketing", "tx_followup"],
    "previous_receipt": "rcpt_01HX7K9M3P4Q5R6S7T8U9V"
  }'

carried_consent is what you claim to hold. The endpoint checks it against the target channel rather than taking it on faith.

200 OK · linked evidence chain

{
  "handoff_id": "hand_01HX7M2N3P...",
  "new_session_id": "sess_wa_4k2j9d",
  "evidence_chain": {
    "previous_receipt": "rcpt_01HX7K9M3P4Q5R6S7T8U9V",
    "linked_receipt": "rcpt_01HX7M2N3P..."
  },
  "channel_disclosure_required": true,
  "disclosure_template_id": "disc_wa_de_v2"
}

channel_disclosure_required is the answer to the question most hand-offs never ask.

Where it runs

Voice sessions, inbound and outbound, with the chain intact across a transfer.
In controlled testing
Hand-off to a human, with the receipt recording where the machine stopped.
In controlled testing
Chat and email as source and target channels.
Planned
WhatsApp and other messaging targets.
In development
Per-channel disclosure templates per jurisdiction.
Germany: national policy layer active. Netherlands: in development. Belgium and Austria: planned.

Why a hand-off matters

Three things change at once, and only one of them is technical.

  • The disclosure duty restarts. Art. 50(5) asks for the information at the first interaction — and on a new channel, that is a new first interaction.
  • The consent may not travel. An opt-in for a phone call is not automatically an opt-in for a message, and the scope of what was agreed sits in the consent record, not in the routing table.
  • The record splits. Two systems, two logs, and an auditor who asked one question now needs two answers. Linking the receipts is what keeps that a single question.

What an auditor asks

“Show me everything this person saw.”

That is one question, and it should have one answer. Linked receipts mean the export follows the person across channels rather than following the channel across people, which is the shape the question actually has.

Questions

What works today?
Voice sessions, with the chain intact across a transfer. A transfer to a person, triggered by the agent, is in controlled testing; automatic hand-off on red-flag signals is in development. Chat and email are planned; until they arrive, this endpoint carries a voice session across a transfer and links the receipts.
Does consent carry over automatically?
No, and the endpoint will tell you so. What you declare in carried_consent is checked against the target channel; where the scope does not cover it, the response says a fresh disclosure or a fresh opt-in is required.
What happens to the previous receipt?
Nothing. It stays where it is and the new one points back at it. Chains are append-only; a hand-off adds a link rather than rewriting history.

One conversation, one record

Proof is the product view: what a linked chain looks like from the outside, and what a reader can recompute from it without a key.

See a receipt

Related