A tag becomes an action
A conversation tagged 'refund' or 'cancel' triggers the webhook, and from there the actual refund or cancellation fires in the system that owns it, logged back onto the ticket automatically.
Help Scout ships a REST API plus webhooks that cover conversations, customers, tags, chats, ratings, and survey responses, enough to read or write almost anything that happens inside the inbox. The API itself is generous. What it doesn't do is decide what happens next when a webhook fires, that part is still a server someone has to build and run.
The REST API reaches most of the inbox. You can create, read, update, and delete conversations, customers, tags, and notes through Help Scout's Mailbox API, and pull mailbox and user data the same way. It's the foundation for anything from a custom sidebar app to a nightly sync job.
Webhooks cover the events that matter. Help Scout fires a webhook when a conversation is created, assigned, moved, merged, or has its status or tags changed; when a customer record is created, updated, or deleted; on every customer and agent reply; when a note gets added; when a rating comes in; and when a chat starts or a survey response lands. That's most of what actually happens in a support team's day, available as a real-time event instead of something you'd have to poll for.
Setup is in the UI, logic is on you. Turning on a webhook is a few clicks under Settings, Workspace, Apps. What happens after Help Scout calls your endpoint, logging it, deciding what to do with it, retrying it if your server was down, is code someone has to write and a server someone has to keep running.
The API gives you data, not judgment. It'll tell you a conversation got tagged 'refund,' but it has no opinion on what a refund should actually do in your payment processor or your order system. That logic, and the authentication, error handling, and retry behavior around it, lives outside Help Scout entirely.
Access also isn't universal. Full API and webhook access sits on specific plan tiers, and OAuth2 app authentication, the standard way to connect securely, takes a bit more setup than copying an API key into a spreadsheet tool.
A conversation tagged 'refund' or 'cancel' triggers the webhook, and from there the actual refund or cancellation fires in the system that owns it, logged back onto the ticket automatically.
A webhook on conversation-created kicks off a lookup in your order or billing system, and the answer lands in the sidebar before an agent even opens the ticket.
If Help Scout already fires the event, the only missing piece is usually the server on the other end.
Walk us through what a tag, a status change, or a new conversation should kick off elsewhere in your business. Help Scout's webhooks almost certainly already fire the event; most of the time the gap is just the receiving end. And if the real bottleneck has nothing to do with your inbox, we'll look at that instead. Help Scout is one system among many we build on top of.
Let's talk →Yes. Help Scout's Mailbox API is a REST API that covers conversations, customers, tags, notes, mailboxes, and users, letting you read and write most of what exists in the inbox programmatically.
Yes, for a wide set of events: conversation created, assigned, moved, merged, or updated; customer created, updated, or deleted; agent and customer replies; notes; ratings; chats; and survey responses. You turn them on under Settings, Workspace, Apps.
To read data through the API casually, not really, there are third-party tools that handle simple syncs. To build something that reacts to webhooks in real time, like triggering an action in another system, yes, you need a server and someone who can write to it.
No. Full API and webhook access is tied to certain plan tiers, so it's worth checking your current plan before assuming a given integration path is open to you.