n-Help Scout's API Covers Almost Everything in the Inbox. Someone Still Has to Build What It Triggers.
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.
What the API and webhooks actually give you
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.
Where it still takes custom code
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.
What this turns into
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.
Customer data arrives before the agent asks
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.
What's the tag or status change that should be doing more than it does right now?
If Help Scout already fires the event, the only missing piece is usually the server on the other end.
Watching Help Scout tags and statuses change without anything downstream reacting to them?
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