Webhook vs Mailhook: Which Trigger Should I Use?

Both give your workflow an address the outside world can hit. Here is how to choose.

Overview

Webhooks and mailhooks solve the same problem: something outside Spojit needs to start your workflow and hand it data. The difference is the transport. A webhook is a signed HTTPS URL that software calls with an HTTP request. A mailhook is a unique email address that anything capable of sending email can reach.

The short version: if the sender is software making an API call, use a webhook. If the sender is a person, a mail rule, or a system that only knows how to send email, use a mailhook.

Side by Side

Sender - Webhook: an application making an HTTP POST. Mailhook: anything that can send an email (a person, a forwarding rule, a vendor portal, a legacy system).
Address - Webhook: a per-workflow URL like https://webhooks.spojit.com/.../your-trigger. Mailhook: a per-workflow email address like invoices-x7k2m9qf4a3vbn8c@mailhook.spojit.com.
Authentication - Webhook: HMAC signature verification with signing secrets (Spojit, Shopify, GitHub, Slack, or custom schemes). Mailhook: the unguessable address itself, plus optional sender and subject filters.
Payload - Webhook: the raw HTTP body, parsed as JSON when possible. Mailhook: the parsed email (sender, subject, text and HTML body, attachment metadata).
Response - Webhook: the caller gets a response, including an execution id it can poll, or even the workflow's output in synchronous mode. Mailhook: the sender gets nothing back; delivery is fire-and-forget.
Latency - Both are push-based and start the run within seconds.
Rotation - Webhook: rotate signing secrets on the connection, with two active secrets for zero-downtime cutover. Mailhook: regenerate the address; the old one stops working immediately.

Pick a Webhook When

The sender is an application or script that can make HTTP requests.
You are integrating a platform with native webhook support, such as Shopify, GitHub, or Slack. Spojit verifies their signatures out of the box.
The caller needs a response: confirmation the run started, an execution id to poll, or the workflow output itself.
You need cryptographic proof of who sent the payload. HMAC signatures authenticate the sender; email cannot.
The payload is structured data (JSON) rather than prose.

Pick a Mailhook When

The sender can only send email: a vendor portal's notification setting, a scanner, a legacy system's emailed reports.
A person is the trigger. Forwarding a message to an address is something everyone already knows how to do.
You want zero setup on the sending side. There is no secret to install and no code to write; the address is the whole integration.
The payload is a message: an invoice, a support request, a report, a notification.
You want to peel a slice off a busy inbox with a forwarding rule instead of connecting the whole mailbox.

Security Differences Worth Understanding

Webhooks authenticate the sender. The HMAC signature proves the request came from someone holding the signing secret. Requests with bad signatures are rejected with an error.
Mailhooks authenticate the address. Anyone who knows the full address can fire the workflow, subject to your filters. The from allowlist is routing hygiene, not authentication, because sender addresses can be spoofed.
Treat a mailhook address like a capability: share it deliberately, and regenerate it if it spreads further than intended.
Both discard unknown traffic quietly. A rotated mailhook address does not bounce, and an invalid webhook signature does not reveal whether the trigger exists.

Can I Use Both?

Yes. A workflow can have multiple triggers, and each is an independent entry point into the same logic. A common pattern is a webhook for the structured API path plus a mailhook for the human path: the order system POSTs to the webhook, while edge cases get forwarded in by the operations team.