email-webhook vs Postmark Inbound

email-webhook vs. Postmark Inbound: Which Should You Use?

Of all the inbound email services available, Postmark Inbound is the closest to email-webhook in design: both give you a dedicated email address without requiring DNS changes, and both deliver mail as JSON. The differences are subtler than those with SendGrid — but they matter. This article walks through them so you can pick the right tool.

How each approach works

Postmark Inbound is part of Postmark's transactional email platform. You create a server, configure an inbound stream, and Postmark gives you an @inbound.postmarkapp.com address (or lets you point your own domain at their MX records). Incoming mail is forwarded to your webhook URL as a JSON POST, authenticated with HTTP Basic Auth.

email-webhook gives you a @email-webhook.com address the moment you sign up. You create a webhook with a URL, optional HTTP method, and any custom request headers. Incoming mail is forwarded as a JSON POST (or PUT, PATCH, DELETE, or GET) immediately.

Side-by-side comparison

	Postmark Inbound	email-webhook
Payload format	`application/json`	`application/json`
Attachments	Inline base64 in JSON array	Inline base64 in JSON array
Authentication	HTTP Basic Auth (username + password on your endpoint)	Custom headers — any name and value you choose
Setup	Account → server → inbound stream → webhook URL	Sign up → create webhook
HTTP methods supported	POST only	POST, PUT, PATCH, DELETE, GET
Custom request headers	Not configurable	Up to 5 per webhook
Email content stored?	Yes — visible in Postmark's activity feed	No — forwarded from memory, never written to disk
Own domain required?	No — `@inbound.postmarkapp.com` provided; own domain optional	No — `@email-webhook.com` provided
Primary product focus	Transactional email sending; inbound is a secondary feature	Purpose-built for receiving email over HTTP

Authentication: custom headers beat Basic Auth

This is the most meaningful practical difference.

Postmark authenticates webhook requests using HTTP Basic Auth — a username and password you set on your endpoint. That means your server needs to decode the Authorization: Basic <base64> header, split out the credentials, and compare them. Every framework handles this a little differently, and Basic Auth credentials are easy to accidentally log or expose in proxy configurations.

email-webhook lets you attach any custom header to every outgoing request. You set a header name and value in the dashboard; email-webhook sends it with every delivery:

POST /webhook HTTP/1.1
X-Api-Key: your-secret-token
Content-Type: application/json

Your handler validates it with a single string comparison:

if (req.headers["x-api-key"] !== process.env.WEBHOOK_SECRET) {
  return res.sendStatus(401);
}

You can use any header convention your stack already knows — Authorization: Bearer, X-Api-Key, X-Webhook-Secret, or anything else. You can add up to 5 headers per webhook, which makes it straightforward to forward different secrets to different downstream services without changing your endpoint logic.

Rotating the secret is a dashboard update — no credential file to reissue, no Basic Auth configuration to rebuild.

Payload: lean versus rich

Both services deliver JSON, but Postmark's payload carries substantially more fields:

{
  "From": "alice@example.com",
  "FromName": "Alice",
  "To": "abc123@inbound.postmarkapp.com",
  "ToFull": [...],
  "Cc": "", "CcFull": [...],
  "Bcc": "", "BccFull": [...],
  "OriginalRecipient": "abc123@inbound.postmarkapp.com",
  "ReplyTo": "",
  "MailboxHash": "",
  "Subject": "Hello",
  "Date": "Thu, 5 Apr 2012 16:59:01 +0200",
  "TextBody": "Hello!",
  "HtmlBody": "<html>...",
  "StrippedTextReply": "",
  "Tag": "",
  "MessageID": "...",
  "Headers": [...],
  "Attachments": [...]
}

email-webhook delivers exactly what most handlers need:

{
  "from": "alice@example.com",
  "to": "abc123@email-webhook.com",
  "subject": "Hello",
  "message": "Hello!",
  "attachments": [...]
}

If you genuinely need CC lists, raw headers, or the HTML body alongside the plain-text body, Postmark's richer payload is useful. For the majority of integrations — support ticket ingestion, automation triggers, AI pipelines — you only ever read from, subject, and the message body. email-webhook gives you those without requiring you to navigate a larger schema or distinguish between TextBody and HtmlBody.

Setup: fewer concepts to learn

Postmark's inbound feature is built around their server and stream model. To get a working address you need to:

Create a Postmark account.
Create a server (Postmark's top-level organisational unit).
Navigate to the server's inbound stream.
Set a webhook URL on the stream.
Optionally configure spam filtering thresholds.

Each of these is a separate step in a dashboard designed primarily around sending email. Postmark's concepts — servers, streams, message streams — make sense in the context of a full email platform, but they add friction if all you want is to receive email over HTTP.

With email-webhook:

Sign up.
Create a webhook with a URL.
Send a test email.

No server abstraction. No stream configuration. No platform concepts to understand before you can receive your first delivery.

Privacy and data handling

Postmark stores incoming messages in its activity feed, visible in the dashboard, for a retention period tied to your plan. That means email content — bodies, subjects, sender addresses — is written to Postmark's infrastructure and queryable after delivery.

email-webhook is a pass-through: mail arrives, is parsed in memory, and is immediately forwarded to your endpoint. The body and attachment content are never written to disk. If you enable Message Logs, only delivery metadata is stored (sender address, subject line, HTTP status, duration) — never the email content itself.

For applications that process business email, personally identifiable information, or confidential notifications, this is a meaningful distinction.

When Postmark Inbound is the right choice

You are already using Postmark for transactional sending and want a single vendor.
You need the richer payload — CC/BCC lists, raw headers, HTML body — and don't want to parse it yourself.
Your stack already handles HTTP Basic Auth cleanly.

When email-webhook is the right choice

You want a simpler setup with no platform concepts to navigate.
You prefer modern header-based authentication over Basic Auth.
You need a clean, minimal JSON payload without schema noise.
You want to use PUT, PATCH, DELETE, or GET in addition to POST.
You need email content to remain private and never be stored by a third party.
You are building something purpose-driven — a serverless function, an AI pipeline, an automation trigger — and want a tool that does exactly one thing well.

Summary

If you're already on Postmark and its richer payload or single-vendor convenience matters to you, Postmark Inbound is a reasonable choice.

If you're starting fresh and want the simplest possible path from incoming email to an HTTP call — with modern authentication, a minimal payload, and no email content retained anywhere — email-webhook is the better fit. Get started in under five minutes →