Inbound email parsing is the work of turning a raw RFC-822 message into structured fields a consumer can actually use — extracting the sender, recipient, subject, plain-text and HTML bodies, selected headers, and any attachments out of nested MIME parts.
Doing it yourself means owning an MX record, an SMTP receiver, a MIME parser, somewhere to put attachments, size limits, and sender filtering. None of that is the application; all of it has to work before the application sees anything.
Parsing is only half the job
Several services parse inbound mail well and hand the result to an HTTP endpoint you nominate. What they hand over is a single POST request. If that request fails because the endpoint was down, if it needs replaying next month, or if you need a record of what arrived and whether it was processed, that remains yours to build.
Hooksbase treats a parsed message as a delivery: it is recorded, retried under the webhook's retry policy, signed, replayable against the configuration captured at the time, and it falls into the DLQ when it ultimately fails.
In Hooksbase
Parsing happens as part of email ingest. The resulting event carries source set to email alongside the parsed fields, so downstream routing rules can match on the channel or on any parsed field such as the subject line.
Related terms
- Email ingest
Accepting an inbound email as an event by sending it to a webhook’s generated ingest address.
Read - Ingest channel
One of the four ways an event enters Hooksbase: HTTP, email, form, or scheduled cron.
Read - Payload
The body of an HTTP request — for webhooks, almost always JSON.
Read - Attempt
One HTTP request within a delivery's retry chain.
Read