Skip to main content
Webhooks will let external systems react to Woes events without polling. Endpoint-level webhook documentation is not published yet.

Planned event categories

Conversations

Created, updated, resolved, assigned, or handed off.

Messages

Customer, operator, or agent message created.

Customers

Customer created, updated, or identity linked.

Issues

Issue created, updated, linked, or resolved.

Knowledge

Source scan completed, failed, or changed coverage.

Agent

Agent answer created, handoff requested, or low-confidence event recorded.

Future delivery docs should include

TopicNeeded detail
Event namesStable event type strings.
Payload schemasIDs, timestamps, workspace scope, and included resource fields.
SigningHow to verify the webhook came from Woes.
RetriesRetry schedule, timeout behavior, and terminal failure state.
IdempotencyHow receivers should dedupe deliveries.
OrderingWhether events are ordered per workspace, resource, or delivery attempt.

Security expectations

Webhook receivers should verify signatures once signing details are published. Payloads should avoid secrets and include enough IDs to fetch additional data through authenticated APIs.
Design webhook consumers to be idempotent. Even well-behaved webhook systems can deliver retries.