Call webhooks

Talk9 can send an HTTPS POST to your application's endpoint after a call's transcript and summary have been processed. The request uses JSON. Delivery waits for collected-data extraction and call analysis to finish; either may produce an empty object if processing fails or no fields are configured.

All generic call webhooks use the same format described below. There is no format selector. Provider-specific adapters, such as eAsistent eHelper, and the Partner API use their own contracts.

Example request

All values below are fictional. The token is a placeholder for a separate, random secret agreed for your integration.

POST /integrations/talk9 HTTP/1.1
Host: receiver.example.com
Authorization: Bearer YOUR_INTEGRATION_TOKEN
Content-Type: application/json

{
  "call_id": "00000000-0000-4000-8000-000000000001",
  "started_at": "2026-10-23T13:00:00Z",
  "ended_at": "2026-10-23T13:02:00Z",
  "duration_seconds": 120,
  "from_number": "+38610000001",
  "to_number": "+38610000002",
  "direction": "inbound",
  "summary": "The caller requested a renovation quote.",
  "collected_data": {
    "email": "caller@example.com",
    "request": "Bathroom renovation"
  },
  "analysis_tags": {
    "email_status": "provided",
    "conversation_stage": "completed",
    "call_type": "new_inquiry"
  },
  "call_url": "https://app.talk9.si/home/example-team/calls/00000000-0000-4000-8000-000000000001"
}

Fields

Extracted data and analysis

collected_data and analysis_tags are separate objects, just as in Talk9. Their keys depend on the agent's configuration. The example keys are not fixed fields of the webhook. Collected values are JSON values; tags use the configured string vocabulary, such as provided, missing or not_applicable, rather than a fixed boolean schema. Extraction and classification are generated by AI and can be incomplete or incorrect.

Transcript and recordings

Transcripts are off by default for each integration. When enabled, the request additionally contains:

{
  "transcript": "Caller: I would like a renovation quote.\nAssistant: What work do you need?"
}

When disabled, the transcript key is omitted entirely. For agents configured to retain only a summary, it is omitted even if the integration requests it. Private temporary processing text is never used for webhook transcripts.

The webhook includes no audio files or recording links, even when old audio-link settings are present. The optional call_url is a link to the authenticated Talk9 application, not direct access to a recording.

Only send content your receiving application needs. Once your endpoint accepts data, you control its storage, access and deletion. Deleting a call in Talk9 does not delete a copy already accepted by your application. Talk9 keeps delivery status without saving another copy of the request content or the receiver's response body in the delivery log.

Receiving a request

1. Provide a public HTTPS endpoint without redirects.
2. Validate your integration's secret before processing the body. Bearer-token authentication is supported, or an agreed custom authentication header.
3. Validate the fields you need. Allow optional fields and future additive fields, and accept empty collected data or analysis tags.
4. Store the request durably, deduplicating by call_id within your integration.
5. Return a 2xx status only after acceptance. Do not return call content or secrets.

The token authenticates Talk9 to your receiver. It is not a Talk9 API key and there is no HMAC signature in this format. Keep the token on your server. Delivery requires HTTPS and header authentication; query-string tokens and redirects are not supported.

The endpoint must resolve only to public IP addresses. Talk9 checks DNS answers when opening each connection and uses those checked addresses for the connection. Private, loopback, link-local and other reserved addresses are rejected, including IPv4 addresses encoded as IPv6. DNS lookup failures stop that attempt.

Timing and delivery limits

The event follows successful summary processing, not the instant the caller hangs up. Empty transcripts, failed summary processing, already deleted calls, and agents in transcript-only mode do not generate this event. If analysis or collected-data extraction fails, delivery can still proceed with the available data. Requiring nonempty collected data is an optional integration setting.

Each integration records one delivery per call, with up to three HTTP attempts for temporary connection failures, timeouts, HTTP 408, 429 or 5xx responses. The two retries wait 1 and 2 seconds respectively. Other HTTP errors, invalid destinations, redirects and certificate errors are not retried. A successful 2xx response ends delivery immediately.

The default timeout is 10 seconds per attempt, configurable from 1 to 30 seconds. A valid Retry-After header can extend the wait to at most 30 seconds; if the receiver requests a longer wait, delivery stops as failed instead of retrying early. Retries use the same JSON body and call_id, so the receiver must deduplicate. A timeout can happen after the receiver has accepted the data.

Retries run within the original delivery process, without a background queue. They do not recover from a stopped process or an extended outage. Before each retry, Talk9 checks that the call content is still available and the integration is still enabled, assigned and unchanged. Deletion, a policy change or an integration change stops further attempts.

Regenerating a summary does not resend a call with an existing delivery record. There is no automatic historical backfill. Enabling an integration may include older calls whose processing is still pending; it does not scan all past calls. Discuss historical export and recovery requirements with Talk9 before relying on this webhook as your only copy of call data.

Migrating an existing integration

This is a breaking change for receivers using the earlier payload. Update and test each receiver before deploying it. There is no per-integration format switch or fallback. The old Slovenian keys and flattened extracted fields are removed. The standard field mappings are:

call_id, summary and optional call_url keep their names. The new format also adds ended_at, duration_seconds, direction, analysis_tags and the optional transcript. Receivers must support duplicates because temporary failures can now retry automatically. Existing eHelper integrations keep their own contract.

Review authentication before deployment: query-string tokens and unauthenticated endpoints must move to a bearer token or custom authentication header over HTTPS. The old include_audio_url and require_audio_url settings have no effect. Collected data is optional by default; set require_collected_data to true if your receiver should only receive calls with nonempty extracted data.

Talk9 configures the following server-side settings for a generic integration. All credentials here are placeholders; never put a real secret in documentation.

{
  "url": "https://receiver.example.com/integrations/talk9",
  "auth": {
    "type": "bearer",
    "token": "YOUR_INTEGRATION_TOKEN"
  },
  "include_transcript": false,
  "include_call_url": true,
  "require_collected_data": false,
  "timeout_ms": 10000
}