Connect Zendesk, Intercom or Freshdesk to engineering
Send only the tickets your agents escalate. Zendesk and Intercom connect in one click, Freshdesk with an API key and one automation rule. Setup takes a few minutes.
Zendesk, Intercom, and Freshdesk are the inbound support providers Watari supports today. All three encrypt credentials at rest and can be disconnected without losing historical bug data.
If your team logs customer problems in an issue tracker rather than a help desk, Watari can pick them up from Jira, Linear, GitHub Issues or Azure Boards instead: see Jira, Linear, GitHub and Azure Boards.
To see what ends up in Jira, Linear, GitHub Issues or Azure Boards once a ticket is escalated, see the integration pages.
What the integrations share
- Encrypted credentials. Tokens (Zendesk/Intercom) and the API key (Freshdesk) are AES-256-GCM encrypted before they are written to the database. They are never logged.
- Verified webhooks. Zendesk and Intercom webhooks are verified against the provider's HMAC signature. Freshdesk has no signed-webhook product, so its inbound webhook is authenticated with a per-tenant secret token you place in a request header (constant-time compared). In every case the ticket is re-fetched from the provider before processing, the webhook body is never trusted for content. Duplicate events are deduplicated by event ID.
- Disconnect without data loss. Disconnecting a support tool stops new tickets from flowing in, but all existing bugs, mappings, and RCAs remain in your Watari workspace.
How they connect differs by provider:
- Zendesk & Intercom use OAuth: one click, a consent screen, and Watari registers its own webhook automatically.
- Freshdesk uses an API key (Freshdesk offers no OAuth for external apps), and you create one Automation Rule that fires when your team escalates a ticket (by assigning it to an Engineering group (or setting the Type)) so only escalated tickets reach Watari. Watari gives you the exact URL, header, and body to paste, about 90 seconds.
Progress notes on the ticket
While an issue that came from your support tool moves through Watari, Watari adds an internal note to the original ticket at each step, the same moments your tracker hears about it:
- Picked up: what Watari found in the ticket. For a question that needs no code change, the drafted answer.
- Found in your code, or Watari asks: whether Watari found where it happens, or the one question it needs answered, with how to answer it in Watari.
- Draft fix in review, merged and live.
- Customer update ready: the update Watari wrote, word for word. Approve it in Watari (edit it first if you like, or skip it) and Watari posts it on the same ticket.
- No draft fix: when Watari stopped without one. Anyone with more detail, the support agent included, can add it in the Watari panel or in Watari and Watari tries again; the note says how many tries are left. When someone added detail, the next note says who and from where, never what they wrote.
Every note ends with Meanwhile, tell the customer: a reply your agent can send right now that never promises more than is true (nothing says "fixed" before the fix is live). Once the customer update is written, the note carries that update instead, since it is the reply to send.
Notes are internal (a Zendesk internal comment, an Intercom note, a Freshdesk private note), so your customer never sees them. Each step is noted once per ticket. To turn them off, open Settings, Connected tools, choose Configure on the support tool and switch off Progress notes on the ticket (owners and admins).
If your organization has multiple Zendesk instances (for example, one for customer support and one for internal IT), only one instance connects per Watari workspace. Use separate Watari workspaces (one per Zendesk subdomain) to route them independently.
Act from the Zendesk ticket sidebar
The Watari app for Zendesk adds a panel beside the ticket. It shows whose move the ticket's issue is and the next step, with the reply you can send your customer now (Add to reply puts it in the reply box, Copy copies it). You do not sign in to Watari: Zendesk tells Watari which agent opened the app, and Watari matches your Zendesk email to a member of the workspace that connected this Zendesk.
What you can press depends on your role in Watari, the same as in Watari itself:
| You are | You can |
|---|---|
| Not a member of the workspace | Read the panel. It names the address to invite. |
| Member | Send the customer update, edit it and send your version (25 to 120 words), or skip it; answer Watari's question; press Draft a fix when the issue is ready for one; when Watari paused or the issue needs an engineer, add what the customer told you that is not in the ticket (the panel asks for what Watari is missing, in its own words) and press Add detail and retry. When only an engineer can supply what is missing, the panel says so instead of offering the box. If what you send is already on the issue, or Watari has already tried it five times that day, the panel says so and when it can try again. |
The panel never marks a fix as live: whether a fix reached production is for your engineers to confirm. While a merged fix waits for that, the panel reads "Waiting for your engineers to confirm it is live." They confirm it from the issue in Watari, from the Slack or Teams card, or with a reply on the tracker item.
Your Zendesk email has to be verified in Zendesk and match the email you use in Watari for the panel to know you. The first time you press a button, the panel gives you a Confirm it is me link instead, right above the button you pressed: open it, sign in to Watari if asked, check that it names you, and press Yes, this is me. Then press the button again. You do this once per help-desk account; your workspace's owners and admins are told each time someone does, and you can unlink it in Settings → Profile. Everything you do from the panel shows on the issue's history as "Zendesk app by" your name. The app is in review and is installed for now as a private app; ask us if you want to try it.
Act from the Intercom inbox
The Watari app for Intercom adds a panel to a conversation's details in the Inbox. It shows the same things as the Zendesk panel: whose move the conversation's issue is, the next step, and what to tell your customer now (select the text to copy it; Intercom does not let an app write into the reply box). You do not sign in to Watari: Intercom tells Watari which teammate opened the app, and Watari matches your Intercom email to a member of the workspace that connected this Intercom.
What you can press depends on your role in Watari, the same as in Watari itself:
| You are | You can |
|---|---|
| Not a member of the workspace | Read the panel. It names the address to invite. |
| Member | Send the customer update, edit it and send your version (25 to 120 words), or skip it; answer Watari's question; press Draft a fix when the issue is ready for one; when Watari paused or the issue needs an engineer, add what the customer told you that is not in the ticket (the panel asks for what Watari is missing, in its own words) and press Add detail and retry. When only an engineer can supply what is missing, the panel says so instead of offering the box. If what you send is already on the issue, or Watari has already tried it five times that day, the panel says so and when it can try again. |
The panel never marks a fix as live: whether a fix reached production is for your engineers to confirm. While a merged fix waits for that, the panel reads "Waiting for your engineers to confirm it is live." They confirm it from the issue in Watari, from the Slack or Teams card, or with a reply on the tracker item.
The panel shows the issue as it was when you opened it or last pressed a button; press Refresh to see the latest. The first time you press a button, the panel gives you a Confirm it is me link instead, right above the button you pressed: open it, sign in to Watari if asked, check that it names you, and press Yes, this is me. Then press the button again. You do this once per help-desk account; your workspace's owners and admins are told each time someone does, and you can unlink it in Settings → Profile. Everything you do from the panel shows on the issue's history as "Intercom app by" your name. The panel is not yet in the Intercom App Store version of Watari; ask us if you want to try it.
Connect your support tool
Connecting Zendesk
In the Watari dashboard, go to Settings → Connected tools and click Connect Zendesk.
Enter your Zendesk subdomain. This is the part before .zendesk.com: for example, if your support portal is at acme.zendesk.com, enter acme.
You are redirected to the Zendesk OAuth authorization screen. Sign in with an account that has admin permissions on the Zendesk instance, then click Allow.
You are returned to Watari. The connection status shows as Connected and a webhook is registered on your Zendesk account automatically.
A dialog opens asking for tags. Add at least one (for example needs-engineering) and save. Watari creates a trigger in Zendesk that forwards every ticket carrying one of those tags. Until a tag is saved, no ticket is sent and the card asks you to Choose tag.
What Watari reads from Zendesk
Ticket subject, body, public comments, internal comments, status, priority, tags, custom fields, requester display name and email, and attachments of any format (screenshots and screen recordings are read visually, PDFs page by page, logs, HAR captures, CSVs, stack traces and Office documents as text, and voice notes including a screen recording's narration are transcribed, see Ticket to bug). Watari reads only the tickets that reach it via webhook, and the only tickets sent are the ones carrying a trigger tag you chose (for example needs-engineering). Your agents decide what Watari sees by applying the tag.
What Watari writes back to Zendesk
A single public comment posted to the ticket after the fix ships to production, the customer-facing RCA (or an internal note, if you choose). Along the way, internal progress notes.
What gets extracted
Ticket content goes through structured extraction: severity, repro steps, expected vs. actual behavior, customer impact, and the customer's original words. Non-bug tickets (billing questions, account access, feature requests) are classified and skipped. They never produce a Mapped Issue.
OAuth errors and reconnection
If the OAuth flow fails partway through (network timeout, user cancels authorization, session expires), go back to Settings → Connected tools and start the connection flow again. OAuth state is short-lived; a fresh flow is the correct fix.
If the integration shows a Connection error status after being connected, it means Watari received a webhook but the token exchange failed or was revoked. Disconnect and reconnect from Settings → Connected tools to re-authorize.
Next: Install the Watari GitHub App and configure CODEOWNERS-driven PR routing: install the GitHub App, select repositories, and configure CODEOWNERS-driven PR routing.
Security and compliance
Token encryption, multi-tenant isolation, compliance status, data residency, and the sub-processor list.
GitHub
Install the Watari GitHub App, select repositories, pick up GitHub issues as reports, configure branch protection prerequisites, and set up CODEOWNERS-driven reviewer routing.