Webhooks and the REST API solve two different problems, and most real integrations need both:
- Webhooks tell you something happened — a matching email arrived, was blocked, or was processed. This is push, near-real-time, and does not require your application to poll anything.
- The API lets you ask or act — pull additional detail about a message, update a routing rule, check a mailbox, or change configuration. This is pull, on-demand.
A typical event-driven workflow uses a webhook as the trigger and the API (or the webhook payload itself, if it carries enough data) to do the actual work. The same rule engine now also supports a file export action as an alternative (or addition) to the HTTP callback — useful when the system on the other end reads files from a directory rather than accepting webhooks; see exporting matched email to EML or text files.
A common startup/SME need: when a customer emails support, create or update a record in the CRM or helpdesk automatically, without a human re-typing anything.
- Configure a webhook rule matching your support address(es) — trigger on recipient, or on a subject/content pattern if you route by topic.
- The webhook fires an HTTP POST containing the email data (sender, subject, body, headers) to an endpoint in your own application or a middleware layer (Zapier, Make, or your own API).
- Your endpoint looks up or creates the customer record by sender address, attaches the message as an activity/ticket, and applies any tags already added by the Router module (see the tagging guide) as CRM fields — category, language, priority.
- Optionally, call back into the mail server's API to mark the message as processed, or to trigger an auto-acknowledgement via the Responder module.
Getting the webhook rule right upfront avoids doing filtering work twice — once in the mail server and again in your application code:
- Scope the webhook narrowly (specific recipients, or content/subject patterns) rather than firing on every message and filtering in your app. This reduces load on your endpoint and keeps the integration simpler to reason about.
- Multiple rules can AND their conditions, and any matching rule fires the webhook, so you can build both AND and OR logic without writing custom filtering downstream.
- Decide early whether you need the full message body in the webhook payload or just headers plus an API call-back for the body — smaller payloads are easier to process reliably, especially if your endpoint has to respond quickly.
A webhook-driven integration that only gets tested on the happy path tends to fail quietly in production. Worth building in from the start:
- Idempotency. If the same webhook fires twice (retried after a slow response, for example), make sure creating a duplicate CRM ticket or duplicate action is not the result.
- Fast responses. Acknowledge the webhook quickly and do slower downstream work (calling a third-party CRM API, for example) asynchronously, rather than making the mail server wait on your endpoint.
- A dead-letter path. Log webhook deliveries your endpoint failed to process so nothing silently disappears — email that should have become a support ticket but didn't is a bad failure mode to discover from an angry customer.
- Monitoring the trigger side, not just your endpoint. See email stats, logs and reporting via API for keeping an eye on the mail server side of the integration.
Hexamail Nexus combines the webhook engine (rule-based HTTP callbacks with AND/OR conditions, full JSON payload) with the Developer module's REST API, so a single product can both notify your application the moment matching mail arrives and let your application call back to look up or change configuration and stored mail. This covers most "connect our mail flow to our own product" integrations without a third-party integration platform in the middle, though tools like Zapier or Make can still sit between the webhook and your app if that suits your stack better.