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

# Webhooks

> Operata delivers enriched contact records, agent-reported issues, and Heartbeat results to your AWS account as Amazon EventBridge events — no HTTP endpoint required.

Operata's webhook mechanism is Amazon EventBridge (not an HTTP POST to a URL you host). After each contact ends — and on other triggers such as agent-reported issues and Heartbeat workflow results — Operata publishes a JSON event to a partner event source in your AWS account. You attach EventBridge rules and route events to any consumer you need.

## Endpoint

There is no HTTP webhook endpoint to register. Delivery flows from Operata to a partner event source dedicated to your Operata account:

```text theme={null}
aws.partner/operata.com/<operata-group-id>/<event-bus-name>
```

You provide the AWS account and region; Operata creates the partner event source and emails you the source name to associate in the AWS console. See [Configure webhooks](/docs/api-webhooks-configure) for the one-time setup.

## Delivery model

EventBridge is Operata's only outbound event channel. Operata does not POST to an HTTPS URL you host. Reasons:

* AWS-native routing. EventBridge rules, targets, and pipes are configuration in your account — no consumer you have to keep online.
* At-least-once delivery from EventBridge to your targets, with the retry and dead-letter behavior you configure on the rule.
* No signing-key rotation, no IP allowlist, no consumer endpoint to monitor. The trust boundary is the partner event source association.

Once you associate the partner event source with an event bus in your account, every event Operata publishes for that account lands on that bus. Filter and fan out from there.

## Event types

| `detail-type`        | When it fires                                                                 | Catalog entry                                                          |
| -------------------- | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| `CallSummary`        | After a contact completes, with the full enriched record.                     | [Call summary](/docs/api-webhooks-events#call-summary)                 |
| `InsightsSummary`    | When Operata establishes one or more insights for a contact.                  | [Insights summary](/docs/api-webhooks-events#insights-summary)         |
| `AgentReportedIssue` | When an agent reports an issue through Agent Messenger.                       | [Agent reported issue](/docs/api-webhooks-events#agent-reported-issue) |
| `HeadsetSummary`     | When headset stats collection is enabled and a contact ends.                  | [Headset summary](/docs/api-webhooks-events#headset-summary)           |
| Heartbeat workflow   | When a Heartbeat test triggers its workflow.                                  | [Heartbeat workflow](/docs/api-webhooks-events#heartbeat-workflow)     |
| CCP log lines        | For CCP log lines at `ERROR` and `WARN`, plus `INFO` for `ICE Connect Error`. | [CCP log files](/docs/api-webhooks-events#ccp-log-files)               |

Each entry in the catalog includes the synopsis, payload shape, and trigger condition.

## Delivery timing

Post-contact events arrive between 30 seconds and 5 minutes after the contact ends. The delay depends on the upstream enrichment pipeline: Contact Trace Record (CTR) availability, Contact Lens output, and signal aggregation. Build consumers that tolerate this window and key off `detail.contact.id.current` rather than wall-clock order.

## Envelope

Every event uses the standard EventBridge envelope. The Operata-specific payload lives under `detail`:

```json theme={null}
{
  "version": "0",
  "id": "530848f3-1111-2222-3333-b33ba70c19f0",
  "detail-type": "CallSummary",
  "source": "aws.partner/operata.com/a28453f9-abab-cdcd-efef-84d9e67ac297/acmeEventBus",
  "account": "083560837128",
  "time": "2026-05-18T05:00:13Z",
  "region": "ap-southeast-2",
  "resources": [],
  "detail": {
    "accountProperties": { "operataGroupId": "a28453f9-abab-cdcd-efef-84d9e67ac297" },
    "contact": { "id": { "current": "ac7a6a89-1111-2222-3333-1e659475d24e" } }
  }
}
```

Filter on `detail-type` to route by event type, and on `source` to scope rules to a specific Operata account.

## Example consumers

* **Network-performance alerting.** Send `CallSummary` events to CloudWatch and use Anomaly Detection on packet loss, jitter, or MOS to surface trends across remote agents.
* **BI dashboards.** Stream `CallSummary` and `InsightsSummary` into Amazon QuickSight, Elasticsearch, or Splunk for contact-quality reporting.
* **Ticket creation.** Route `AgentReportedIssue` through Lambda into your ticketing system, attaching the full payload — browser, system, and softphone error — to the ticket.

## Versioning

Event payloads follow the same additive-change policy as the REST API: new optional fields ship without notice; breaking changes ship under a new `detail-type` or a new partner event source. See [Versioning](/docs/api-versioning) for the full policy and deprecation headers.

EventBridge events do not carry the REST API's `Deprecation` or `Sunset` headers. Watch the [API changelog](/docs/api-changelog) for event-shape changes.

## Related

* [Configure webhooks](/docs/api-webhooks-configure) — create the partner event source and associate it with an event bus.
* [Event catalog](/docs/api-webhooks-events) — payload shape and trigger for every event type.
* [Versioning](/docs/api-versioning) — how Operata signals additive and breaking changes.
* [API changelog](/docs/api-changelog) — announcements for new event types and payload changes.