Skip to main content
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:
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 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

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:
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 for the full policy and deprecation headers. EventBridge events do not carry the REST API’s Deprecation or Sunset headers. Watch the API changelog for event-shape changes.
  • Configure webhooks — create the partner event source and associate it with an event bus.
  • Event catalog — payload shape and trigger for every event type.
  • Versioning — how Operata signals additive and breaking changes.
  • API changelog — announcements for new event types and payload changes.