> ## 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.

# EventBridge

> Operata publishes every contact, agent, and Heartbeat event to a partner event bus in your AWS account via Amazon EventBridge — no HTTP endpoint required.

Operata delivers every contact, agent, and Heartbeat event to your AWS account through Amazon EventBridge — you receive events on a partner event bus and route them with standard EventBridge rules.

## How it works

Operata holds a SaaS partner registration with AWS. When you enable the integration, Operata creates a partner event source in your AWS account. You bind it to a partner event bus, and from that point every Operata-generated event lands on that bus. You then route events — to Lambda, SQS, Step Functions, Kinesis, an HTTP API destination, or any other EventBridge target — with standard EventBridge rules and event patterns.

Events carry the contact, agent, or Heartbeat run they describe, plus the signals and insights Operata attached during processing. The event envelope follows Amazon's `aws.partner/operata.io/...` source convention, so EventBridge rules match on `source` and `detail-type` exactly as they do for AWS-native events.

Delivery is at-least-once. Operata publishes each event once the corresponding observation finalizes; AWS handles delivery to your bus. Your downstream targets own idempotency — if the same event `id` appears twice, treat the second copy as a duplicate, not a state change.

```mermaid theme={null}
flowchart LR
    A[Operata observation] --> B[Operata EventBridge publisher]
    B --> C[Partner event source]
    C --> D[Your partner event bus]
    D --> E[EventBridge rule]
    E --> F[Lambda / SQS / Splunk / etc.]
```

## Why Operata uses EventBridge instead of HTTP webhooks

EventBridge replaces the per-customer HTTP webhook pattern most SaaS APIs use. Instead of Operata pushing to an endpoint you operate — with the retries, signature verification, and IP allowlisting that pattern requires — AWS owns the transport into your account and you own the routing inside it.

For customers already on AWS — every Amazon Connect customer by definition — this means no public endpoint to expose, no shared-secret rotation, and no separate retry logic. EventBridge rules already cover filtering, transformation, dead-letter queues, and cross-account fan-out, so the integration inherits those capabilities instead of re-implementing them.

EventBridge events are AWS-scoped. If you need to deliver events to a destination outside AWS, terminate the event chain at an EventBridge API destination, an SQS queue polled by an external worker, or a Lambda that forwards onward. There is no separate non-AWS webhook path.

## Related

* [Webhooks overview](/docs/api-webhooks-overview) — delivery model, envelope, and example consumers.
* [Configure webhooks](/docs/api-webhooks-configure) — bind a partner event source to a partner event bus in your AWS account.
* [Event catalog](/docs/api-webhooks-events) — every `detail-type`, its payload, and when it fires.
* [Customer Journey Trace](/docs/concepts-customer-journey-trace) — journeys emit events as new spans land, so downstream systems can react to handoffs before assembly completes.
* [Signals and observations](/docs/concepts-signals-and-observations) — what gets carried in an EventBridge event's `detail` payload.
* [Cloud Orchestrator](/docs/concepts-cloud-orchestrator) — Heartbeat runs publish through the same EventBridge path.
* [Cloud Collector](/docs/concepts-cloud-collector) — the AWS-side service that produces the observations EventBridge then ships.