Loading…
Use case · Developers
You want your code to receive email. You do not want to configure MX records, parse multipart MIME, or hand-roll a retry queue. Create an address, point a pipeline at your endpoint, and every matching email arrives as versioned, HMAC-signed JSON.
what lands on your endpoint
POST /hooks/email HTTP/1.1
X-HideMy-Signature: t=1756713600,v1=9f2ab04c…
{
"version": "2026-09-01",
"event": "email.received",
"alias": "bookings@you.hidemy.world",
"email": {
"subject": "Your booking is confirmed",
"from": "no-reply@trains.example",
"text": "Hi, booking ABC123 is confirmed…",
"message_id": "<20260901.7f3a@trains.example>",
"auth": { "spf": "pass", "dkim": "pass", "dmarc": "pass" }
},
"transformed": {
"fields": { "booking_code": "ABC123" }
}
}The problem
# the yak-shaving
# with hidemy.world
Trust, then read
verify the signature · node
import crypto from "node:crypto";
// X-HideMy-Signature: t=1756713600,v1=9f2ab04c…
export function verifyWebhook(rawBody, header, secret) {
const { t, v1 } = Object.fromEntries(
header.split(",").map((kv) => kv.split("="))
);
const expected = crypto
.createHmac("sha256", secret)
.update(t + "." + rawBody)
.digest("hex");
return crypto.timingSafeEqual(
Buffer.from(expected, "hex"),
Buffer.from(v1, "hex")
);
}HMAC-SHA256 over t + "." + body, compared timing-safe. Reject anything that doesn’t match, or with a stale t if you want replay protection too.
read-only rest api · pro
# Read back what an address received (Pro)
curl "https://api.hidemy.world/v1/emails?alias=bookings&limit=20" \
-H "Authorization: Bearer hm_live_5Xw…"
{
"data": [
{
"id": "em_01jf8…",
"alias": "bookings@you.hidemy.world",
"subject": "Your booking is confirmed",
"received_at": "2026-09-01T08:12:44Z"
}
],
"has_more": false
}Reconcile, backfill, or audit what an address received. Read-only by design: a leaked key can look, never send.
Plumbing included
[version]
The version field is a date. Additive changes never break you; breaking changes ship as a new version you opt into per pipeline.
[hmac]
Every POST carries an HMAC-SHA256 signature over timestamp.body. One timing-safe comparison and forged calls are dead on arrival.
[retry]
Non-2xx or timeout? Exponential backoff, every attempt logged per event, and a replay button for when your endpoint is fixed.
[dedupe]
Duplicate inbound mail is dropped by Message-ID before it reaches your pipeline. Retries reuse the same event, so replays are safe.
[egress]
Webhook delivery refuses private address ranges and redirects into them, so endpoint URLs can’t be turned into an internal-network probe.
[auth]
Authentication results ride along in every payload, and your rules can gate on them: drop unauthenticated mail before it’s delivered.
[rest]
List and fetch received emails over REST on Pro. Read-only by design: there is no outbound scope to leak, ever.
[eml]
Upload a real .eml, run it through your transformer, and diff the extracted fields, all before anything touches production.
How it works
bookings@you.hidemy.world in a couple of clicks. No domain purchase, no MX records, no SMTP daemon to keep alive.
Paste your URL, grab the signing secret, optionally add rules and a transformer. Fire a test email from the dev tools and watch the delivery log.
Your feature is one HTTP handler: verify the signature, read the fields, done. Retries, dedupe, logs and replay are our problem now.
No testimonials, just configs
Plans
Prototype the whole pipeline: Free
2 addresses, 100 emails a month, webhooks and signatures included. No card. Enough to prove the integration end to end this afternoon.
The developer tier: Pro
€24.90/mo: the read-only REST API, 5,000 emails a month, unlimited transformers, 1,000 AI evaluations, 5 team members and up to 365-day retention.
Somewhere in between? Lite (€9.90/mo) has unlimited addresses and 1,000 emails a month. Compare all plans
FAQ
A non-2xx response or a timeout triggers exponential backoff: the gaps grow from seconds to hours, spread over roughly a day of attempts. Every attempt is logged against the event with status code and latency, and once your endpoint is healthy again you can replay any delivery manually from the dashboard.
Delivery is at-least-once, so design for replays. Inbound mail is already deduped by Message-ID upstream, and retries reuse the exact same payload and signature timestamp. Key your processing on email.message_id (plus the alias if you fan one sender into several addresses) and handling a delivery twice becomes a no-op.
version is a date, e.g. 2026-09-01. Within a version we only ever add fields. Write your parser to ignore unknown keys and it will never break. Anything backwards-incompatible ships as a new dated version that you opt into per pipeline; existing pipelines keep receiving the version they were built against.
Send yourself test emails straight from the dev tools in the dashboard (no waiting on a real sender) and watch each delivery attempt in the log. Point the pipeline at a tunnel (ngrok, cloudflared) to hit localhost, and use .eml uploads to iterate on transformers without sending anything at all.
Fair use. The real ceilings are your plan’s email quota (100/mo on Free, 1,000 on Lite, 5,000 on Pro) and the REST API is fair-use limited on top. If you do hit a limit you’ll get a 429 with Retry-After, not a silent drop. Bursty inbound traffic is fine; deliveries queue and drain.
Create an address, point a pipeline at your endpoint, and receive your first signed JSON payload in the next ten minutes. Free, no card.