Webhooks and events
Which provider events Watari subscribes to, how retries and signed payloads work, and what happens when a delivery fails.
TL;DR
Webhooks and events
An overview of the event surface Watari sits on — what it listens to and what it sends out.
Incoming webhooks — what Watari receives
Watari subscribes to events from four external systems. Every inbound webhook is HMAC-signature verified on receipt. Payloads that fail signature verification are rejected with a single 401 response and are never retried by Watari.
Zendesk
Watari registers its own webhook on your Zendesk account during the OAuth flow. Events received:
- Ticket created — triggers extraction.
- Ticket updated (customer reply added, status changed) — re-queues extraction if the update contains new customer content.
Intercom
Watari subscribes to conversation events on your workspace during OAuth. Events received:
- Conversation created — triggers extraction.
- Conversation part added (customer message or teammate message) — re-queues extraction on new customer content.
GitHub
The GitHub App subscription covers the events needed for code mapping, PR lifecycle, CI status, and deploy detection. Key subscriptions:
| Event | Why Watari uses it |
|---|---|
push | Incremental reindex when your default branch changes |
pull_request | Detect PR merge or close; kick off RCA flow |
pull_request_review | Reviewer comment iteration — triggers re-generation |
issue_comment | Reviewer comment iteration via issue-thread comments on PRs |
check_run / check_suite | CI verify-loop trigger + passive CI status surfacing |
status | Legacy commit-status from CI providers that don't use Checks API |
deployment_status | Production deploy detection — triggers RCA publish when configured |
installation | App lifecycle (install, uninstall, suspend) |
Razorpay
Watari receives subscription lifecycle events from Razorpay. These drive billing state — activating subscriptions, handling payment failures, advancing dunning states, and triggering the monthly overage invoice close.
What triggers the Watari pipeline
Not every inbound event starts full processing. The events that trigger the ticket-to-bug pipeline are:
- A new Zendesk ticket or Intercom conversation arrives.
- A Zendesk ticket or Intercom conversation receives a new customer reply (existing ticket, new content).
- A GitHub PR review comment is left on a Watari-drafted PR (triggers PR iteration).
- A GitHub CI check result lands on a Watari-drafted PR (triggers CI verify-loop, if enabled).
- A GitHub deployment_status event arrives for a production environment (triggers RCA publish, if configured).
Outbound events — what Watari sends
Watari posts to connected destinations when pipeline stages complete.
| Destination | When Watari posts |
|---|---|
| Slack | New Mapped Bug, cluster-grew alert, PR opened, PR merged, PR failed, RCA published |
| Linear | New Mapped Bug → Linear issue created |
| Jira | New Mapped Bug → Jira Story created |
| GitHub | Draft PR opened, review requests sent, PR comments posted (iteration feedback) |
| Zendesk | RCA posted as a public ticket comment after fix ships |
| Intercom | RCA posted as a conversation reply after fix ships |
Watari does not currently provide a customer-facing webhook subscription API. If you need to receive Watari events in your own systems — for example, to sync Mapped Bugs into an internal tool — contact us at /contact. Outbound webhook subscriptions are on the roadmap.
Retry behavior
Failed outbound deliveries. When Watari posts to Slack, Linear, or Jira and the request fails, it retries with exponential backoff. The retry limit is managed by Watari's job queue — it isn't a customer-configurable setting.
Slack channel errors. If Slack returns a channel-gone error (channel_not_found, is_archived, not_in_channel), Watari stops posting to that channel and marks the integration as errored rather than retrying indefinitely. A monthly background job rechecks errored integrations and recovers automatically if the channel is available again. See Routing and notifications — Slack channel-invite step for the invite-bot step that prevents the most common cause of this.
Linear and Jira delivery failures. If issue creation fails for Linear or Jira — expired token, project permissions changed, API error — the failure appears on the bug detail page as a delivery error. Reconnect the integration from Settings → Integrations to resume.
Inbound verification failures. A webhook that fails HMAC verification gets a single 401 response. Watari does not retry from its side — the sending system (Zendesk, Intercom, GitHub, Razorpay) will retry according to its own retry policy if it receives a non-2xx response.
Next: Disconnecting integrations — token revocation and data retention windows — token revocation, what data persists after disconnect, and full deletion.
Routing and notifications — Slack, Linear, Jira
Configure where Watari posts updates and where draft tickets land. Includes the Slack channel-invite step and the Jira ADF requirement.
Disconnecting and data handling
What happens when you disconnect an integration — token revocation, retention windows, and full deletion.