DEV Community: yobox

How to Use DisposableEmail Safely (WithoutLocking Yourself Out)

yobox — Mon, 15 Jun 2026 16:25:04 +0000

Disposable email feels like a cheat code. Hand the form an address that exists for an hour, get whatever you came for, walk away. No spam. No mailing list. No "we noticed you haven't logged in" guilt-trips three years later.

But disposable email has a dark side, and it's not a security one — it's a self-inflicted one. The number-one reason people regret using temp mail is locking themselves out of an account they actually wanted to keep. This guide is about avoiding that, and about using disposable email in a way that actually improves your security posture instead of quietly hurting it.

The Single Rule

Before any tactics: never use disposable email for an account you'd be upset to lose.

That's the whole framework. Everything else is a refinement of how to tell which accounts those are. If you'd cry over losing it — your bank, your domain registrar, your Apple ID, your Steam library, your GitHub, your Stripe — use a real email or an alias. If you wouldn't blink — a forum, a one-time download, a coupon — disposable is great.

When Disposable Email Is the Right Tool

These are the canonical good fits:

Downloading a "free" resource that requires email (PDFs, whitepapers, lead magnets).
Reading a forum post locked behind a signup wall.
One-time purchases from a vendor you'll never buy from again.
Testing your own software. Sign up to your own app to make sure the email flow works.
Beta access to a service you might never actually use.
Newsletter previews. Subscribe, read one issue, decide.
For the developer cases, the YoBox Temp Mail tool is purpose-built — fast addresses, OTP-friendly delivery, and a JSON API for automated tests.

When Disposable Email Will Hurt You

These are the cases where users get burned:

Account recovery. No real address → no password reset → permanent lockout.
Two-factor backup codes. If your 2FA email is the disposable one, you're a phone-loss away from disaster.
Receipts you'll need later. Tax time will find you.
Anything tied to a phone number. When the SMS comes asking you to "confirm via email," you'll be hunting for an inbox that no longer exists.
Subscriptions. Renewal warnings, billing changes, and cancellation confirmations all go to email.

A Tiered Strategy for Real Life

Free tool
Try YoBox Temp Mail
Disposable inbox — no signup, instant OTP.

Open
The cleanest way to think about email isn't "real vs disposable" — it's a three-tier system:

Tier Use for Tool
Tier 1: Real Bank, government, work, anything you'd cry to lose Gmail / Outlook / ProtonMail
Tier 2: Alias Per-service permanent identities, online shopping, social media SimpleLogin, Apple Hide My Email, ProtonPass
Tier 3: Disposable One-off signups, downloads, testing YoBox Temp Mail
Tier 2 is the one most people skip and most regret skipping. Aliases give you a unique address per service that forwards to your real inbox — so when you start getting spam to netflix-2023@yourdomain, you know exactly who leaked. You can kill the alias without touching your real address.

Safety Practices for Disposable Inboxes

If you're going to use temp mail, do it right:

Copy the address — and the inbox URL
Most temp mail services let you re-open the same inbox later if you saved the URL. YoBox stores your address locally so it survives a page reload. Always copy the address and note the service, in case you need to come back.
Read the email before closing the tab
This sounds obvious. It is not. Half the "I lost access" stories start with "I copied the OTP, pasted it, closed the tab, and then the site said wait for a second verification email."
Don't reuse a disposable address for a second account
Disposable inboxes are often public or guessable. If you used one for Account A and someone else gets the same address tomorrow, they can request a password reset on Account A and read the code.
Treat OTPs as time-sensitive
A 6-digit code with a 10-minute window means a 10-minute disposable inbox is fine, but a 60-second one is not. See "Why OTP Verification Fails (and How to Fix It)" for more on timing.
Never paste sensitive content into a temp inbox preview
Some services display message bodies in plaintext on shared infrastructure. If a sender accidentally emails you something private (an API key, a contract, a personal note), don't assume the inbox is private just because it's "yours."
Be aware of legal grey zones
Most sites' ToS forbid disposable email. You won't be sued, but your account can be terminated without notice — including any data inside it. Don't store anything important there. See "Is Disposable Email Legal and Safe?".

A Workflow That Works

Here's the actual workflow we use:

Default to an alias. SimpleLogin or Apple Hide My Email for almost everything. One alias per service.
Use disposable for true one-offs. PDF downloads, beta signups, things you'll never log into again.
Use the real address only for tier 1. Bank, work, government, critical accounts.
Keep a password manager. Disposable addresses become very, very hard to remember; if you ever do need to log back in, a password manager that remembers a8f3kq@somedomain.com saves you.

Disposable Email for Developers

If you're a developer testing your own app, disposable email is the correct tool, not a workaround. Don't pollute your real inbox with 400 password resets while you're QAing the auth flow. Use a disposable address. The YoBox Temp Mail JSON API lets you spin up a fresh inbox programmatically, trigger a signup, and read the OTP — see "Email Testing Guide for Developers" for code samples.

Pair it with the Webhook Tester when your signup flow also fires a backend webhook (Mailgun, Postmark, SendGrid all do this) and you want to assert on both halves of the flow.

FAQ

Can I use disposable email for online shopping?
For one-time purchases, sure — but use an alias if you might need warranty or return support.

What if the site detects disposable email and blocks me?
Try a different provider with a fresher domain. Some services rotate domains specifically to dodge blocklists.

Is it safe to receive password reset codes on a temp address?
Only for accounts you don't care about losing. If the account has anything important, use a real address.

Can I migrate an account from a disposable email to a real one?
Most sites let you change your account email from inside settings — but only if you can still log in. Plan ahead.

Does using temp mail mark me as a spammer?
Not directly. But many sites distrust disposable signups and gate features (e.g. Reddit, Discord) until you "upgrade" to a real address.

Bottom Line

Disposable email is a scalpel, not a hammer. Use it for the things it's good at — anonymous one-offs, developer testing, dodging marketing lists — and use aliases or real addresses for everything else. The YoBox Temp Mail tool is built for the cases where temp mail is genuinely the right answer; the rest of the time, an alias service or your real inbox will serve you better.

Email Testing Guide for Developers (2026 Edition)

yobox — Sun, 14 Jun 2026 11:16:38 +0000

Email is the test surface nobody wants to own. It's asynchronous, depends on external providers, has its own version of "flaky" (sometimes a delivery just… takes 90 seconds), and the bugs that bite hardest in production — wrong template variables, broken unsubscribe links, OTPs that expire too fast — are the ones unit tests can't catch.

This guide is the working developer's playbook for testing email in 2026. We'll cover the three layers (unit, integration, end-to-end), the tooling for each, and the patterns that actually scale.

The Three Layers of Email Testing

| Layer | What you're testing | Tooling | |---|---|---| | Unit | Template rendering, variable substitution, plain-text fallback | Jest / Vitest with snapshot tests | | Integration | Your app correctly calls your email provider's API | Provider sandbox or mock SDK | | End-to-end | The email actually arrives and the user can complete the flow | YoBox Temp Mail + Cypress / Playwright |

Most teams cover unit. Many cover integration. Few cover end-to-end — and that's exactly where the production bugs live.

Layer 1: Unit Tests for Templates

If you're using a templating engine (MJML, Handlebars, JSX-email, React Email), render the template with test data and snapshot the output. Catches:

Missing variable substitutions (Hello, {{name}} rendered with no name)
Broken HTML
Missing plain-text fallback
Localization bugs
test('welcome email renders', () => {
const html = renderWelcomeEmail({ name: 'Ada', verifyUrl: 'https://example.com/v/abc' });
expect(html).toMatchSnapshot();
expect(html).toContain('Hello, Ada');
expect(html).toContain('https://example.com/v/abc');
});
These tests are cheap, fast, and catch the "template rendered with undefined literally in the body" class of bugs.

Layer 2: Integration Tests for Send Logic

Your app calls Postmark / SendGrid / SES / Resend with a payload. The integration test asserts that you call the provider with the right payload, not that the email arrives.

Most providers ship a test mode or a sandbox endpoint. Use it.

test('signup triggers verification email', async () => {
const sendSpy = vi.spyOn(emailProvider, 'send');
await signup({ email: 'test@example.com' });
expect(sendSpy).toHaveBeenCalledWith(expect.objectContaining({
to: 'test@example.com',
template: 'verify-email',
variables: expect.objectContaining({ code: expect.stringMatching(/^\d{6}$/) }),
}));
});
You'll catch: - Wrong recipient - Wrong template - Missing variables - Codes outside expected format

You will not catch: - The email being rejected by Gmail's spam filter - The OTP arriving 90 seconds late - The magic link 404'ing because the route changed

Those need end-to-end.

Layer 3: End-to-End with Disposable Inboxes

This is where most teams give up. Don't.

The pattern, in one paragraph: spin up a real disposable inbox via API, submit a real signup with that address, let the email actually traverse SMTP, poll the inbox until the message arrives, parse out the OTP or link, submit it back to your app, assert the user is now signed in.

Full implementation in "How to Test Email Flows Without a Real Inbox" — works in Cypress, Playwright, or any HTTP-capable runner.

The YoBox Temp Mail API is designed for this loop: no auth, no rate limit on normal use, no captcha. The address generates in under a second, OTPs typically arrive in 2–5 seconds, and inboxes persist long enough for slow senders (SES, in-house SMTP).

Pair with Webhook Testing

Many email flows also fire downstream webhooks. SendGrid fires processed, delivered, opened; Postmark fires Delivery, Open, Click. To fully test, point those webhooks at the YoBox Webhook Tester during your test run, and assert on both halves:

Trigger signup
Wait for OTP email
Verify code
Wait for user.verified webhook on your test endpoint
Assert on both This catches the production-only bugs: the email sent but the webhook didn't fire (bad downstream config), the webhook fired but with wrong payload, the order-of-operations bug where the user clicks before the webhook lands.

Common Test Scenarios

Signup with OTP
test('signup', async ({ page, request }) => {
const inbox = await createTempInbox(request);
await page.goto('/signup');
await page.fill('[name=email]', inbox.address);
await page.click('text=Send code');
const code = await pollForOtp(request, inbox.token);
await page.fill('[name=otp]', code);
await page.click('text=Verify');
await expect(page).toHaveURL(/dashboard/);
});
Password Reset
test('password reset', async ({ page, request }) => {
// (assume user already exists at inbox.address)
await page.goto('/forgot');
await page.fill('[name=email]', existingUser.email);
await page.click('text=Reset password');
const msg = await pollForEmail(request, existingUser.token);
const link = msg.text.match(/https:\/\/[^\s]+\/reset\?token=\S+/)?.[0];
await page.goto(link);
await page.fill('[name=password]', 'new-pw');
await page.click('text=Save');
await expect(page.locator('text=Password updated')).toBeVisible();
});
Double Opt-In
test('newsletter confirmation', async ({ page, request }) => {
const inbox = await createTempInbox(request);
await page.goto('/subscribe');
await page.fill('[name=email]', inbox.address);
await page.click('text=Subscribe');
const msg = await pollForEmail(request, inbox.token);
const confirmLink = msg.text.match(/https:\/\/[^\s]+\/confirm\?\S+/)?.[0];
await page.goto(confirmLink);
await expect(page.locator('text=Subscription confirmed')).toBeVisible();
});

Deliverability Testing

Unit and integration tests can't tell you if Gmail will route your message to spam. For that, you need:

Mail-tester.com for one-off checks (paste a generated address, send your email, get a deliverability score).
GlockApps or similar for ongoing inbox-placement monitoring.
DMARC reports for production sender health.
These aren't replacements for the test layers above; they're a separate axis.

Anti-Patterns to Avoid

Snapshot the entire HTML email and break on every CSS tweak. Snapshot the key text + structure, not the whole document.
Use your real personal Gmail for test signups. You'll regret it.
Stub email entirely in E2E tests. You'll miss the bugs E2E exists to find.
Share one disposable inbox across parallel tests. Race conditions on messages.
Set OTP TTL to 60 seconds "for security." Real users with slow inboxes can't complete the flow.

Tooling Cheat Sheet

| Need | Tool | |---|---| | Render template snapshots | Jest / Vitest | | Mock email provider SDK | provider's own test mode or vi.spyOn | | Disposable inbox for E2E | YoBox Temp Mail | | Capture downstream webhooks | YoBox Webhook Tester | | Local SMTP catcher for dev | Mailhog, MailCatcher | | Deliverability score | mail-tester.com | | Inbox-placement monitoring | GlockApps |

FAQ

Should I test against staging or production email providers? Staging if available. Production providers usually have a test mode (Postmark "Sandbox", SendGrid "Sandbox Mode") that returns success without actually delivering.

How do I avoid hitting send rate limits in CI? Cap parallelism, use disposable addresses (so the recipient never hits its rate limit), and reserve full E2E runs for nightly builds.

Can I run these tests in GitHub Actions? Yes. YoBox Temp Mail and Webhook Tester have no auth and no captcha, so they work in any CI.

What about testing email in mobile apps? Same pattern — the disposable address is platform-agnostic, you just drive the mobile UI with Detox or Appium instead of Playwright.

Do I need a separate domain for test emails? Not strictly. But sending from a different from address in tests (e.g. test@yourdomain) keeps your production sender reputation clean.

Bottom Line

Email testing has three layers and you should cover all three. Unit tests catch template bugs. Integration tests catch send-logic bugs. End-to-end tests with disposable inboxes and webhook capture catch the bugs that only show up when the email actually flies. Skip any layer and you'll find the bug in production instead of CI.

A practical guide to OTP verification, password resets, transactional emails, deliverability testing, and the workflows modern developers and QA teams use to validate email systems in 2026.

A Docker Builder Recipe for Cypress & Playwright in CI

yobox — Sat, 13 Jun 2026 11:06:01 +0000

Containerized e2e is the difference between a green build and a four-hour debugging session over Slack DM. "Works on my machine" stops being funny the third time it happens. This guide gives you a battle-tested Dockerfile and docker-compose.yml for running Cypress and Playwright in CI, plus the YoBox plumbing that keeps disposable inboxes and webhook receivers out of your container image.

The Docker Builder tool scaffolds the baseline; this article explains the why behind every line.

What good looks like

A solid e2e container has five properties:

Deterministic — same image, same result, this year and next.
Cached — node_modules and browser binaries don't re-download every run.
Shardable — N replicas, N× faster, no shared state.
Small enough — under ~1.5 GB so pulls don't dominate wall-clock time.
Observable — traces, screenshots, and videos survive the run.
YoBox helps with property 3 by giving every shard its own disposable inbox and webhook URL over plain HTTP. No mail server in the compose file, no tunnel sidecar.

Base image choice

Both Playwright and Cypress publish official images. They are large but they save you from chasing missing Chromium libs at 1 AM. Use them.

Playwright

FROM mcr.microsoft.com/playwright:v1.49.0-jammy

Cypress

FROM cypress/included:14.0.0
If you need both in one image (rare, but useful for golden tests), start from the Playwright image and npm i cypress on top — Cypress brings its own Electron, Playwright brings its own browsers, and they coexist fine.

رA production Dockerfile

```dockerfile FROM mcr.microsoft.com/playwright:v1.49.0-jammy

WORKDIR /app

1. Dependencies — separate layer for cache reuse COPY package.json package-lock.json ./ RUN npm ci --no-audit --no-fund

2. Browsers (Playwright auto-installs in base image; uncomment if pinning) # RUN npx playwright install --with-deps

3. Source COPY . .

4. Default env ENV CI=1 \ YOBOX=https://yobox.dev/api \ PWDEBUG=0

ENTRYPOINT ["npx", "playwright", "test"] ```

Key choices:

npm ci not npm install — reproducible installs.
Source copied after deps so a one-line spec change doesn't blow the cache.
YOBOX baked in so tests have a sane default but can be overridden per environment.

docker-compose for local parity

```yaml services: app: build: ./web ports: ["3000:3000"]

e2e: build: ./tests environment: - BASE_URL=http://app:3000 - YOBOX=https://yobox.dev/api depends_on: - app command: ["--shard=1/1"] ```

That's it. No mail server. No webhook tunnel. The tests reach YoBox over the public internet, which is exactly what CI does too — meaning your local run matches CI byte-for-byte.

Sharding in CI

GitHub Actions, four shards:

jobs:
e2e:
strategy:
matrix: { shard: ["1/4", "2/4", "3/4", "4/4"] }
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: docker compose build e2e
- run: docker compose run --rm e2e --shard=${{ matrix.shard }}
Because every test asks YoBox for its own inbox and its own webhook URL, the shards never collide.

Cache strategy

Image pulls are the single biggest cost in containerized e2e. Two tricks:

uses: docker/setup-buildx-action@v3
uses: docker/build-push-action@v6 with: context: ./tests cache-from: type=gha cache-to: type=gha,mode=max load: true tags: e2e:latest GHA's registry cache turns a cold 4-minute build into a 20-second warm build.

Trace and video artifacts

Mount an output volume and upload on failure:

run: docker compose run --rm -v "$PWD/test-results:/app/test-results" e2e
if: failure() uses: actions/upload-artifact@v4 with: name: traces-${{ matrix.shard }} path: test-results Pair Playwright's trace: "on-first-retry" with this and every flaky failure ships you a viewable trace.

Image size: what actually matters

| Layer | Size | Notes | | -------------------- | -------- | ------------------------------------ | | Playwright base | ~1.2 GB | Includes Chromium, Firefox, WebKit. | | Cypress base | ~1.4 GB | Includes Electron + Xvfb. | | node_modules | 200–500 MB | Cacheable separately. | | Source | <10 MB | Negligible. |

Stripping browsers you don't use saves more than micro-optimizing layers. Pick one browser engine per suite when you can.

Pairing with YoBox

Inside the container, every helper is a one-liner:

const inbox = await fetch(process.env.YOBOX + "/mail/new", { method: "POST" }).then(r => r.json());
That's all the integration code you need. The Cypress guide and Playwright guide cover the full fixture patterns.

Common pitfalls

npm install in CI. Always npm ci. Always.
--ipc=host missing for Chromium. Without it, Chromium crashes under load. docker run --ipc=host ...
Mounting the host node_modules. Don't. Native modules differ between host and container.
No browser pinning. Tag the Playwright base image with an exact version. latest will betray you.
Skipping retries. Set retries: 1 in CI to absorb single-request blips without masking real bugs.

FAQ

Can I run this on ARM (M-series Macs)? Yes — both Playwright and Cypress publish multi-arch images.

How do I avoid pulling the image every run? Use a self-hosted runner with a Docker volume, or GHA's registry cache.

Should I bake node_modules into the image? Yes for CI, no for local dev where you bind-mount source.

Where do I store test reports? Upload as an artifact and link from the PR. Don't commit them.

Conclusion

Containerized e2e is non-negotiable for any team running tests across more than one machine. The recipe above — official base image, npm ci, sharded compose, GHA cache, YoBox-backed inboxes and webhooks — gets you to a green pipeline in an afternoon. Generate your starting Dockerfile from the Docker Builder and customize from there.

See also: The Only docker-compose.yml Pattern You Need, Cypress + YoBox, Playwright + YoBox.

Multi-stage builds for smaller images

For self-hosted runners with bandwidth caps, a multi-stage build keeps only the runtime needed for tests:

\`dockerfile FROM mcr.microsoft.com/playwright:v1.49.0-jammy AS deps WORKDIR /app COPY package.json package-lock.json ./ RUN npm ci

FROM mcr.microsoft.com/playwright:v1.49.0-jammy WORKDIR /app COPY --from=deps /app/node_modules ./node_modules COPY . . ENTRYPOINT ["npx", "playwright", "test"] \`

Pinning vs floating tags

\v1.49.0-jammy\ is reproducible across years; \latest\ is reproducible for about 12 hours. Pin in CI, float in personal sandboxes.

GHA cache versus self-hosted

The GitHub Actions cache is fast but capped per repo. Self-hosted runners with a persistent Docker volume win above ~50 e2e jobs per day. Below that, GHA cache is simpler.

Migration tips

Most teams adopting containerized e2e do it after they've outgrown a single CI machine. The migration order that works: containerize the test runner first, then add sharding, then move to a self-hosted runner pool once cache pressure shows up.

Webhook Testing: The Complete Guide for 2026

yobox — Fri, 12 Jun 2026 13:36:27 +0000

Webhooks are how modern systems talk to each other asynchronously. Stripe sends them. GitHub sends them. Shopify, Slack, Twilio, Postmark, SendGrid, Mailgun, Auth0, Clerk, Supabase, and every payment processor on the planet sends them. If your app integrates with anything, you're either receiving webhooks, sending them, or both.

And yet testing webhooks is still painful. The traditional setup involves ngrok tunnels, a local server you have to keep running, a way to replay payloads, and a way to debug the headers and signatures. This guide is the complete playbook for testing webhooks in 2026, including the patterns that finally let you do it from a browser tab.

What a Webhook Actually Is

A webhook is an HTTP POST that a provider sends to a URL you give them when an event happens on their side. That's it. No magic, no special protocol, just HTTP.

The challenge is everything around the POST:

Authentication. Most providers sign the payload with HMAC. You have to verify the signature before trusting the body.

Delivery semantics. At-least-once delivery is the norm — you'll get duplicates. You need idempotency.
Retries. Most providers retry on 5xx for hours. You need fast 2xx returns and a queue.
Order. Webhooks are not ordered. charge.refunded can arrive before charge.succeeded.
Latency. Some providers send within milliseconds; some take minutes.
You need to test all of these, ideally without provisioning real infrastructure.

The Old Way: ngrok + a Local Server

Classic flow: 1. ngrok http 3000 2. Copy the random URL. 3. Paste it into the provider's webhook config. 4. Trigger an event in the provider's UI. 5. Watch your terminal for the request. 6. Repeat for every payload variant.

Problems: - ngrok URLs rotate on the free tier; reconfigure provider every restart. - You need to actually write a server just to log the payload. - Comparing two payloads means scrolling terminal output. - Sharing a payload with a coworker means screenshots.

The New Way: Browser-Based Webhook Capture

The YoBox Webhook Tester gives you a unique URL like https://yobox.dev/webhook/ that captures any HTTP request sent to it and shows you the headers, query, and body in real time, in the browser. No server. No ngrok. Works from CI.

Use it when:

You're integrating with a new provider and want to see what they actually send.

You're debugging why your endpoint isn't responding the way you expect.
You're comparing payload shapes across event types.
You need to share a payload with a coworker (just send the URL).
You're running automated tests that need to assert on webhook delivery.
A Concrete Testing Workflow
Let's say you're integrating Stripe webhooks.

Generate a capture URL.

Open YoBox Webhook Tester. You get https://yobox.dev/webhook/

Paste it into Stripe's dashboard.

Subscribe to the events you care about (payment_intent.succeeded, charge.refunded, etc.).

Trigger events in Stripe's test mode.

Use Stripe's CLI: stripe trigger payment_intent.succeeded.

Watch the request log fill in.

You see the full headers (including Stripe-Signature), the query, and the JSON body. Inspect, copy, compare.

Iterate on your real handler.

Now you know exactly what Stripe sends. Build your handler against the real shape, not the docs (which are sometimes out of date or omit fields).

Testing Your Own Handler

Once your handler is built, flip the flow. Have your test suite:

POST a known payload to your handler.

Assert on the side effects (database row created, downstream API called, etc.).
You can replay captured payloads from the Webhook Tester by copying the body and POSTing it back to your local server. For automated tests, use the YoBox Webhook API — your handler calls out to a downstream service in tests, you point that service at the YoBox capture URL, and your test asserts on what your handler sent.

Common Webhook Bugs to Test For

These are the production bugs we see most often:

Signature verification skipped in dev

Common pattern: if (process.env.NODE_ENV === 'development') skipVerify(). Then someone forgets to turn it back on. Always test that an unsigned request gets rejected.

Body parsed before signature verified

Most signature schemes hash the raw body. If Express body-parser converts it to JSON first, the hash doesn't match. Use express.raw() for webhook routes specifically.

Idempotency missing

The same payment_intent.succeeded event arrives twice. Your handler creates two database rows. Always include an idempotency check (typically by the provider's event ID).

Slow 2xx response

Your handler takes 30 seconds to do downstream work. The provider times out at 10 and retries. Now you're processing the same event 6 times in parallel. Always return 2xx within 1 second and queue the actual work.

Out-of-order events

charge.refunded arrives before charge.succeeded. Your handler crashes because the charge doesn't exist yet. Always fetch from the provider as source of truth; don't trust event order.

Test events leaking into production

Stripe test-mode events have livemode: false. Always check it. We've seen production handlers process test events and refund real customers.

Webhook Testing in CI

The full pattern:

Your CI spins up the app.

A test generates a YoBox webhook URL.
The test configures your app to send downstream webhooks to that URL.
The test triggers the action.
The test polls the YoBox API for the captured request.
The test asserts on the headers and body.

```ts test('order completion fires webhook', async ({ request }) => { const captureUrl = 'https://yobox.dev/webhook/' + crypto.randomUUID(); await configureMyApp({ webhookUrl: captureUrl }); await request.post('/orders', { data: { items: [...] } });

const captured = await pollWebhook(captureUrl); expect(captured.headers['x-myapp-event']).toBe('order.completed'); expect(captured.body.total).toBeGreaterThan(0); }); ```

Webhook Security Testing

A security checklist for any webhook handler you write:

Signature is verified before any side effects. No DB write, no downstream call until hmac.equals() returns true.

Timing-safe comparison. crypto.timingSafeEqual, not ===.
Timestamp checked for replay. Most providers include a timestamp; reject if older than 5 minutes.
Raw body preserved. Never reparse before verification.
HTTPS only. Don't accept webhooks over HTTP.
Allowlist sender IPs if the provider publishes them. Stripe, GitHub, and Twilio all publish IP ranges.
Webhook Testing for Specific Providers
Quick provider-specific notes:

Stripe: use the Stripe CLI's stripe listen + stripe trigger for local. Use YoBox Webhook Tester for staging.

GitHub: the "Redeliver" button in the webhook UI is gold for testing handler changes.
Shopify: test from the admin's webhook log, which can replay any past event.
Twilio: the request inspector shows the full payload Twilio sent — pair with YoBox for archives.
Slack: Slack signing secret has a specific concatenation format; test verification with a known-good payload.
Auth0 / Clerk: both retry aggressively. Make sure your handler is idempotent before testing.
See "Webhook Testing Without ngrok" for a deeper dive on each provider.

FAQ

Do I still need ngrok for webhooks? Not for inspection. For actually receiving webhooks against code running on your laptop, yes. For just seeing what a provider sends, YoBox Webhook Tester replaces ngrok entirely.

How do I test signed webhooks? Inspect with YoBox to confirm the signature format, then write a signature-generating helper for your tests that signs known payloads and POSTs them to your handler.

How long do captured requests stay in YoBox? For the life of the token (typically up to several hours). Save what you need.

Can I replay a captured webhook to my local server? Yes — copy the body and curl/POST it. The webhook log shows everything you need.

Can webhook URLs be public? Anyone with the URL can POST to it. That's the point. Use rotation if you're worried about random traffic.

Bottom Line

Webhook testing in 2026 doesn't require ngrok, a local server, or a tunnel. Use the YoBox Webhook Tester for inspection and capture; build idempotency and signature verification into your handler; test the full async loop in CI by pairing webhook capture with disposable email for end-to-end coverage. Your future self — the one not debugging duplicate charges in production — will thank you.