> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tryopencomputer.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Webhooks and call events

> Connect conversation results to your own service.

Athena has several distinct outbound and inbound integration paths:

| Mechanism | Purpose |
| - | - |
| Workflow webhook | Send data from the configured workflow step to your service. |
| HTTP tool | Make a request while executing an agent action. |
| Call-event destination | Export configured call events through the selected integration. |
| Telephony callback | Receive provider events inside Athena. |

Configure the mechanism that matches your use case; they do not share one universal payload or delivery guarantee.

## Configure a post-call webhook

1. Open the agent's canvas and add **Webhook**. It runs after the conversation and has no conversation edges.
2. Set **Enabled**, **HTTP Method**, and **Endpoint URL**. Select **Authentication** from your saved credentials and add custom headers if your receiver needs them.
3. Set **Payload Template** to the JSON object your receiver expects. Reference the run, initial context, gathered context, or QA annotations only where those values are actually available.
4. Save, test with a temporary receiver you control, and correlate the received marker with the completed run. Check both the payload and authentication. Publish the workflow when verified.
5. Build receiver deduplication around the stable delivery identifier before enabling actions with side effects.

Example payload template:

```json theme={null}
{
  "run_id": "{{workflow_run_id}}",
  "case_reference": "{{initial_context.case_reference}}",
  "purpose": "athena-webhook-check"
}
```

Use the context paths observed in your run for extracted values; defining a variable is not proof that every run populated it. Workflow webhooks are post-call delivery. Use an [HTTP tool](https://docs.tryopencomputer.com/guides/tools.md#configure-an-http-api-tool) when an action must happen during the conversation.

## Verify your receiver

Use a temporary receiver under your control. Send synthetic data, verify the observed method and payload, and test how your receiver handles repeated deliveries and non-success responses.

## Workflow webhook contract

The workflow webhook renders your configured `payload_template` once. For object payloads, it adds `call_disposition` if your template did not already supply it.

The current wire headers retain their existing names:

| Header | Meaning |
| - | - |
| `X-Dograh-Delivery-Id` | Stable delivery identifier; use it to deduplicate retries. |
| `X-Dograh-Workflow-Run-Id` | The associated run. |
| `X-Dograh-Delivery-Attempt` | The delivery attempt number. |

These are correlation headers, not cryptographic signatures. Use the configured credential and authentication mechanism expected by your receiver.

Network failures and HTTP 408, 425, 429, 500, 502, 503, and 504 are eligible for retry. The delivery is stored and retried with backoff; exhausted attempts and permanent failures become dead-letter deliveries. Limits depend on deployment configuration.

Both an HTTP-tool request and a post-call workflow webhook have been observed at a controlled receiver. The post-call test matched a unique marker in the configured payload and included `call_disposition` after the controlled SIP run completed. Retry and dead-letter behavior is covered by local tests; a live delivery-failure drill has not been performed.

## Call-event delivery

The call-event exporter makes up to three delivery attempts within a bounded window. It can discard events if the destination changes, export remains unsuccessful, or the bounded queue is full. It is not an unlimited durable delivery queue.

These exporter semantics do not establish the behavior of a workflow webhook. Verify each integration separately.

For destination fields, required BigQuery schema, authentication, and the connection-test procedure, see [Set up tracing and call events](https://docs.tryopencomputer.com/guides/observability.md#prepare-a-bigquery-call-events-table).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.