An HTTP callback that pushes events (e.g. inbound email) to a URL, used to turn mail into tickets in real time.
Webhooks are how a system reacts to events the instant they happen, rather than polling. See the API docs.
How it works
You register a URL with the source system and tell it which events you care about. When one of those events occurs, the source sends an HTTP request — usually a POST with a JSON body describing what happened — to your URL. Your endpoint does whatever the event calls for and returns a success status. It’s the inverse of an API call: instead of you asking “anything new?” on a schedule, the other side tells you the moment there is.
Webhooks vs polling
The alternative is polling — checking a mailbox over IMAP or hitting an API every minute to ask whether anything changed. Polling wastes requests when nothing has happened and still adds lag when something has. Webhooks are near-instant and cheaper at rest, at the cost of needing a publicly reachable endpoint that’s always up. Many integrations use both: webhooks for speed, periodic polling as a backstop in case a delivery is missed.
Common pitfalls
- Verify the sender. A webhook URL is public, so anyone could POST to it. Reputable sources sign each payload (often an HMAC in a header) — check the signature before trusting the data.
- Expect retries and duplicates. If your endpoint is slow or returns an error, most senders retry, so the same event can arrive twice. Make handling idempotent, keyed on the event id.
- Respond fast. Acknowledge with a 2xx quickly and do heavy work asynchronously; senders treat a slow response as a failure.
A worked example
An e-commerce store’s email provider receives a customer reply and immediately POSTs the parsed message to the help desk’s webhook URL. The endpoint matches it to an open conversation by reference, appends the reply, and the ticket updates in the agent’s queue within a second — no inbox poll in between. The same pattern feeds order-status changes or chat events into the same shared inbox.
How Cherryrise handles it
Cherryrise both receives webhooks — inbound mail turned into tickets in real time — and can send them, firing on events like ticket created, replied, or closed so you can drive downstream automation in tools like Slack or Linear. Outbound payloads are signed so your endpoint can verify they came from your workspace. Details are in the API docs.