DEV Community: yobox

Why OTP Verification Fails (and How to Fix It)

yobox — Wed, 12 Aug 2026 16:19:01 +0000

You typed the code. You're sure you typed it right. The site says "Invalid or expired code." You request a new one. Same thing.

OTP failures are one of the most frustrating UX patterns on the modern web, because they fail silently and the error messages are useless. Here are the seven real reasons OTP verification fails, in order of how often we actually see them in user reports and our own debugging.

1. The Code Already Expired

OTPs typically live 5–10 minutes. By the time you opened the email, read the code, switched tabs, and pasted it, you may have burned 9 minutes of the window — especially if the email was delayed in transit.

Fix: request a new code. Type it immediately. Don't go make coffee.

Developer note: if you're building an OTP flow, surface the exact expiry time in the email and the form. "This code expires at 14:32 UTC" beats "expires in 10 minutes" by a mile.

2. The Code Was Already Used

OTPs are typically single-use. If you mis-clicked Verify twice, or if a browser autofill submitted the form once and then again, the second attempt fails — even though the code is correct.

Fix: request a new code. Don't double-click. Watch for autofill.

3. The Email Was Silently Rejected

If you used a disposable email address, the site may have rejected your address at submission time without telling you. The form said "we sent a code"; nothing was actually sent.

Fix: if you suspect this, try with an email alias instead of a disposable address. Many sites accept aliases while blocking disposable domains.

4. The Email Went to a Spam Folder You Can't See

For temp mail users, this is silent death — temp inboxes don't have spam folders, so a filtered message is just gone. For real inbox users, it's a 30-second hunt.

Fix: check spam in your real inbox. For temp mail, regenerate the address and try again from a different provider. See "Receive OTP Codes with Temp Mail".

5. You're Verifying With the Wrong Address

Some flows let you request OTPs for any address you type, then verify by typing the address plus the code. If you typed the address slightly differently the second time (capitalization, trailing space, alias variant), the code won't match.

Fix: copy-paste both the address and the code. Never retype.

6. The Site's Clock Is Wrong

This is rare on modern infrastructure but still happens — especially on self-hosted apps and small SaaS. If the server's clock is skewed by more than the OTP TTL, valid codes appear expired.

Fix: nothing you can do from outside. Email the site's support.

7. Rate Limiting

If you've requested 5 codes in 10 minutes, most senders silently stop delivering. The code "didn't arrive" because the system refused to send it.

Fix: wait 10 minutes. Don't spam the "resend code" button.

How to Diagnose, in Order

If your OTP is failing, walk this list:

Did the email actually arrive? Check the timestamp.
Are you within the expiry window?
Have you tried this exact code before?
Is the email address you're verifying with exactly the one the code was sent to?
Did you request more than 3 codes in the last 10 minutes?
Are you using a disposable address that the site silently rejects?
Most failures resolve at step 1 or 2.

OTP Best Practices for Developers

If you're building an OTP flow, these are the patterns that hurt users least:

Use 6 digits, not 4. 4 digits is brute-forceable in seconds.
Set TTL to 10 minutes, not 60 seconds. A minute is hostile.
Allow at least 5 attempts per code. Typos happen.
Rate-limit at 3 codes per 10 minutes. Enough to handle real users, blocks abuse.
Don't invalidate the code on a typo. Invalidate after 5 failed attempts or on success.
Show the expiry time in the form. Not just "expires soon."
Send the code in the subject line. Mobile users see it without opening the email.
Echo the requesting IP / device in the email. Helps users spot account-takeover attempts.
For testing your own OTP flow, the YoBox Temp Mail tool gives you a disposable inbox in under a second; pair it with the Webhook Tester if your verify endpoint also fires backend webhooks (some auth providers send a "user.verified" webhook you'll want to assert on).

A Minimal Test Loop

If you're QA'ing OTPs in CI, this is the pattern:

test('signup with OTP', async ({ page }) => {
const { address, token } = await tempMail.createInbox();
await page.goto('/signup');
await page.fill('[name=email]', address);
await page.click('text=Send code');

const code = await tempMail.pollForCode(token, {
timeout: 30_000,
pattern: /\b(\d{6})\b/,
});

await page.fill('[name=otp]', code);
await page.click('text=Verify');
await expect(page).toHaveURL('/dashboard');
});

Full walkthrough in "Email Testing Guide for Developers".

OTP vs Magic Links

A close cousin: magic links. Same idea (one-time token in email), different UX (you click instead of type). The failure modes are nearly identical, with one addition: magic links break when opened in a different browser than the one that requested them. If you request the link on desktop and open it on mobile, many implementations refuse.

For testing, YoBox Temp Mail handles both — you can extract a 6-digit code with a regex or fetch the link and follow it programmatically.

FAQ

Why does Discord say my OTP is invalid even when it's right?
Most often: you used a disposable address Discord silently rejected; the email never arrived. See "Temporary Email for Discord".

Why does the same code work in Chrome but not Safari?
Likely a cookie / session mismatch. The code is tied to a session ID stored in a cookie; switching browsers breaks the link.

Can I extend the OTP expiry?
Not as a user. As a developer, yes — but anything over 15 minutes hurts security.

Why does my OTP arrive twice?
Some senders retry on transient failures. Use the first code; the second is usually the same value resent.

Is SMS OTP more reliable than email OTP?
Generally yes for delivery speed (SMS is often instant), but SMS has its own failure modes (SIM swap, carrier filtering) and is more expensive for the sender.

Bottom Line

OTPs fail for boring reasons more often than exciting ones — expiry, double-clicks, blocklisted disposable domains, rate limits. Walk the diagnostic list before assuming the site is broken. If you're building OTP flows, optimize for human typos and slow inboxes, not the happy path.

YoBox Team

Builder behind YoBox — a privacy-first toolbox for developers and QA engineers covering disposable email, webhook capture, regex, secure passwords, Docker, and end-to-end testing.

Temporary Email for Developers: The Definitive Guide

yobox — Sun, 09 Aug 2026 16:53:19 +0000

Most articles about temp mail are written for people who want to dodge marketing emails. This one isn't. This is the developer's guide to disposable email — how it fits into your workflow, the patterns that scale, and the specific tools that pair with the rest of a modern stack.

By the end you'll know exactly when to reach for a disposable inbox, how to plug it into CI, how to pair it with webhook testing, and how to keep your real inbox sane while you build.

What Developers Actually Use Temp Mail For

The use cases that matter for working developers:

Testing your own signup flows. Don't sign up to your app 400 times with your real Gmail.
CI-driven E2E tests. Cypress, Playwright, or Postman tests that need to receive a real OTP.
OAuth provider testing. New OAuth provider integrations need test accounts on those providers.
Beta product evaluation. You want to try a SaaS product without putting it on your real email forever.
Disposable accounts for sketchy services. That npm package's signup wall, that Stack Overflow clone, that AI tool with a 7-day trial.
Bot / service accounts. A CI service that needs its own identity.
Verifying email-required signup walls. Reading a Reddit thread, downloading a PDF.
For everything in this list, disposable email is the right tool. For things not in this list (your own production accounts, anything with billing, anything you want to recover), use an alias or real email — see "Disposable Email vs Real Email vs Aliases".

The Developer Toolkit

The four tools every developer should have set up:

Tool Use for
Real email Your identity, work, billing, recovery
Email alias service (SimpleLogin / Apple Hide My Email) Per-service permanent addresses
YoBox Temp Mail One-off testing, CI, throwaway signups
Local SMTP catcher (Mailhog / MailCatcher) Local dev where email shouldn't leave the machine
Each has a clear role. Mixing them up is how you end up with 12 password resets for the same forum in your work inbox.

Pattern 1: Testing Your Own Signup Flow

Your app sends an OTP at signup. You want to test the flow without using your personal email.

The pattern:

Open YoBox Temp Mail in a new tab.
Copy the address.
Submit your signup form with it.
Read the OTP from the disposable inbox.
Paste back.
Inspect the resulting user state.
For a manual debug session, this is the fastest possible loop. For automated tests, see pattern 2.

Pattern 2: E2E Tests in CI

For CI, you want the same loop fully scripted. The YoBox Temp Mail tool exposes a JSON API designed for this:

`ts // Create inbox const inbox = await fetch('https://yobox.dev/mail/account', { method: 'POST', headers: { 'content-type': 'application/json' }, body: JSON.stringify({ address: test-${Date.now()}@yobox-test.dev,
password: crypto.randomUUID(),
}),
}).then(r => r.json());

// Trigger signup
await fetch('https://myapp.com/signup', {
method: 'POST',
headers: { 'content-type': 'application/json' },
body: JSON.stringify({ email: inbox.address }),
});

// Poll for message
const msg = await pollForEmail(inbox.token, 30_000);
const code = msg.text.match(/\b(\d{6})\b/)?.[1];

// Verify
await fetch('https://myapp.com/verify', {
method: 'POST',
headers: { 'content-type': 'application/json' },
body: JSON.stringify({ email: inbox.address, code }),
});
`

Full Cypress and Playwright versions in "How to Test Email Flows Without a Real Inbox".

Pattern 3: Pair with Webhook Capture

Many signup flows fire backend webhooks alongside the email — Stripe's customer.created, your own user.verified, Mailgun's delivery events. To test the full async loop, pair Temp Mail with the Webhook Tester:

Generate a disposable inbox.
Generate a webhook capture URL.
Configure your app to use both.
Trigger the signup.
Assert on the OTP email arriving.
Assert on the downstream webhook firing.
This is how you catch bugs like "the email goes out but the webhook never fires because the after-hooks crashed silently."

See "Cypress E2E with YoBox Disposable Email and Webhook Tester".

Pattern 4: OAuth Provider Testing

You're integrating Sign in with GitHub. Your test needs a fresh GitHub account.

Honest answer: don't use disposable email for this. GitHub blocks it. Use an alias for a long-term test account. See "Temporary Email for GitHub".

For providers that do allow disposable email (some smaller OAuth providers, niche identity services), YoBox Temp Mail works fine — same flow as the signup pattern.

Pattern 5: Beta / Trial Accounts

You want to try a new product. You don't want them having your real email forever. Three options:

Alias for products you might actually adopt.
Disposable for products you'll evaluate once.
Real email if the product needs to talk to you long-term (billing, support).
When in doubt, alias. Disposable for true one-offs.

Pattern 6: Bot / Service Accounts

You need an account for a CI process to use. Two clean options:

Custom-domain alias
Set up ci-bot@yourcompany.dev. Forwards to a real address. Survives forever. This is the right answer for any long-lived bot.

YoBox + persistence
For short-lived CI accounts (per-test isolation), generate a fresh YoBox inbox per test run. Don't try to make it long-lived.

Reducing Inbox Spam

A side benefit of using disposable email aggressively: your real inbox stays clean. The compound effect over 5 years is the difference between an inbox that takes 10 minutes to triage daily and one that takes 60.

The rule that works: default to disposable for everything that isn't tier 1 (bank, work, government, password manager). Use aliases for anything you'd want to receive mail from. Reserve your real email for the small set of accounts that matter most.

What to Build Into Your Dotfiles

If you do a lot of email testing, automate the boring parts:

A shell function mail-temp that hits the YoBox API and copies a fresh address to your clipboard.
A Cypress / Playwright command (cy.disposableEmail()) that returns an inbox object.
A snippet in your test fixture library that polls for OTPs with a regex.
A Slack / Discord shortcut that opens YoBox Temp Mail and the Webhook Tester side by side.
Once these are muscle memory, email testing stops being friction.

Security Reminders

Even for developers, temp mail isn't a security tool:

Inboxes are addressable. Anyone who knows the address can read it (modulo token-based auth).
Don't reuse addresses for unrelated accounts. Password reset cross-pollution is a real risk.
Don't put production secrets through temp mail. It's for fake test users, not real credentials.
Rotate addresses per test run in CI. Avoid shared state.

FAQ

Can I use temp mail for my own production app's emails?
No. Production accounts need persistent inboxes. Use temp mail to test the email flow, not as the actual receiver for real users.

How do I avoid hitting rate limits?
Generate fresh addresses per test. Don't reuse one address for 50 sequential signups — that's what triggers sender-side abuse heuristics.

Does YoBox Temp Mail work in CI / GitHub Actions?
Yes — no auth, no captcha, no rate limit on normal use. Designed for CI.

Can I receive attachments?
The API exposes message bodies; attachments are visible in the browser UI but not currently programmatically downloadable.

Is it safe to use disposable email for OAuth testing?
Yes for providers that accept it (most small / mid). No for providers that block it (GitHub, Google, Discord). See provider-specific posts.

Bottom Line

Temp mail is one of the most underrated developer tools. Used right, it cleans up your real inbox, accelerates your test loop, and pairs with webhook capture for full async coverage of complex flows. The YoBox Temp Mail tool was built specifically for developer workflows — fast, scriptable, no nonsense. Add it to your toolkit and stop signing up to your own app with yourname+test001@gmail.com.

YoBox Team

Builder behind YoBox — a privacy-first toolbox for developers and QA engineers covering disposable email, webhook capture, regex, secure passwords, Docker, and end-to-end testing.

Testing API Responses Seamlessly with Postman and YoBox

yobox — Wed, 05 Aug 2026 17:23:38 +0000

Postman is great at one thing: firing a request and asserting on the response body. It's not great at the moment immediately after, when your API quietly sends an email, queues a job, or POSTs to a partner webhook. That side-effect surface is where most production bugs hide, and where most Postman collections silently stop testing.

YoBox closes the gap. A disposable inbox you can poll over HTTP. A webhook URL that records everything. Both work natively with pm.sendRequest and Newman, no SDK required.

This guide walks through the patterns we use for serious Postman + YoBox API testing.

The mental model

Your API does three kinds of work in response to a request:

Returns a body — Postman already tests this.
Sends an email — YoBox Temp Mail tests this.
Hits an outbound webhook — YoBox Webhook Tester tests this.
A complete API assertion covers all three.

Setting up the environment

Create two collection variables:

yoboxBase → https://yobox.dev/api
apiBase → your service URL
Add a startup folder with two requests:

POST {{yoboxBase}}/mail/new
POST {{yoboxBase}}/hooks/new
Each saves id and address / url into collection variables. Every subsequent request can reference them.

Asserting response shape

Postman's Tests tab handles the basics:

pm.test("status 201", () => pm.response.to.have.status(201));
pm.test("returns user id", () => {
const body = pm.response.json();
pm.expect(body.id).to.match(/^[0-9a-f-]{36}$/);
pm.expect(body.email).to.eql(pm.collectionVariables.get("inboxAddress"));
});
Use the Regex Patterns cheat sheet for common assertions (UUID, JWT, ISO timestamps, currency).

Asserting email side effects

The email arrives after the request returns. Wait for it in a pre-request script on the next request:

const id = pm.collectionVariables.get("inboxId");
const base = pm.collectionVariables.get("yoboxBase");
const wait = (ms) => new Promise((r) => setTimeout(r, ms));

async function poll() {
return new Promise((resolve, reject) =>
pm.sendRequest(${base}/mail/${id}/messages, (err, res) =>
err ? reject(err) : resolve(res.json())
)
);
}

(async () => {
for (let i = 0; i < 20; i++) {
const data = await poll();
if (data.messages?.length) {
const msg = data.messages[0];
pm.collectionVariables.set("otp", (msg.text.match(/\b\d{6}\b/) || [""])[0]);
pm.collectionVariables.set("emailSubject", msg.subject);
return;
}
await wait(1500);
}
throw new Error("Email timeout");
})();

Then assert the captured values:

pm.test("welcome email arrived", () => {
pm.expect(pm.collectionVariables.get("emailSubject")).to.include("Welcome");
pm.expect(pm.collectionVariables.get("otp")).to.match(/^\d{6}$/);
});

Asserting webhook side effects

// In the Tests tab of the trigger request
const hookId = pm.collectionVariables.get("hookId");
const base = pm.collectionVariables.get("yoboxBase");

setTimeout(() => {
pm.sendRequest(${base}/hooks/${hookId}, (err, res) => {
const data = res.json();
pm.test("webhook fired", () => pm.expect(data.count).to.be.above(0));
pm.test("payload shape", () => {
const body = JSON.parse(data.requests[0].body);
pm.expect(body.event).to.eql("invoice.paid");
});
});
}, 2000);

For Newman in CI, prefer a dedicated assertion request after the trigger so the timing is deterministic.

Comparison table

Test target Postman alone Postman + YoBox
Response body shape Yes Yes
Response timing Yes Yes
Email delivery No Yes
Email content No Yes
Webhook delivery No Yes
Webhook payload shape No Yes

Running in CI

run: npx newman run collection.json -e env.json --reporters cli,junit env: YOBOX_BASE: https://yobox.dev/api Newman supports pre-request scripts and pm.sendRequest exactly like Postman, so the patterns above run unchanged.

Pairs with

Cypress + YoBox for browser-side flows that depend on API responses.
Playwright + YoBox for cross-browser API + UI tests.
Realistic Mock Data for body fixtures.
Password Generator for credentials.

Common pitfalls

Trusting a 200 as proof of side effects. A 200 says the request was accepted, not that the side effect ran.
Polling too fast. 1.5 s is the right interval for email; 500 ms is the right interval for in-process webhooks.
Forgetting environments. Use Postman environments for apiBase so the same collection runs against staging and production.
Asserting on HTML email bodies. Always parse the plain-text part.

FAQ

Can I test gRPC or GraphQL?
Yes — Postman supports both. The YoBox plumbing is identical because it's just HTTP polling.

Does Postman's Flows feature work with YoBox?
Yes — model the wait-for-email step as a delay + HTTP request node.

How do I share a collection without leaking the YoBox URL?
Use an environment variable, not a hard-coded base.

What about file attachments?
The messages endpoint returns attachment metadata; download via a follow-up request.

Conclusion

A Postman collection that only asserts on response bodies tests half your API. Wire YoBox into pre-request scripts and the Tests tab, and the same collection now verifies emails and webhooks too — in Postman, in Newman, in CI. Two fixtures' worth of code, dramatically more coverage.

Further reading: The Complete Postman Guide, Cypress + YoBox, Regex Patterns Every QA Engineer Should Memorize.

Advanced: contract testing with YoBox webhooks

Treat the YoBox-captured payload as the source of truth for your partner's contract. Snapshot the JSON shape on a green build and fail subsequent runs that drift from it.

Advanced: response time SLAs

Pair \pm.expect(pm.response.responseTime).to.be.below(500)\ with a YoBox-verified side effect to assert both that the API was fast and that the work actually happened.

Migration: from manual to monitored

Postman Monitors run collections on a schedule. Once your collection asserts emails and webhooks via YoBox, you can promote the same collection into a monitor and get continuous production verification for free.

Reporting

Newman's JUnit output drops cleanly into any CI dashboard. YoBox-backed assertions look identical to response-body assertions in the report, so there's no new vocabulary for QA to learn.

A deeper Postman workflow

Postman is famous for one-off requests, but the real value shows up when you treat collections like code: versioned, reviewed, and runnable in CI. The trick is to combine Postman's environment variables with YoBox's ephemeral primitives so every run is hermetic.

Environment design
Create three environments — local, staging, and ci. Each carries:

baseUrl — the API under test
hookId — refreshed per run from Webhook Tester
tempEmail — refreshed per run from Temp Mail
runId — a UUID generated in a pre-request script
// Collection-level pre-request
if (!pm.environment.get("runId")) {
pm.environment.set("runId", crypto.randomUUID());
}
Chaining requests
Postman's request chaining lets you treat a multi-step flow — signup → verify email → create resource → wait for webhook — as a single test artifact. Each step writes to collection variables that downstream steps consume.

// After "create resource"
const id = pm.response.json().id;
pm.collectionVariables.set("resourceId", id);
pm.test("resource created", () => pm.expect(id).to.be.a("string"));
Async assertions
Async webhooks are the bane of API testing. Polling the YoBox Webhook Tester from a Postman test gives you a deterministic wait without sleeping arbitrary durations.

Postman + Newman in CI/CD

Newman is Postman's CLI runner and the bridge between Postman the IDE and your pipeline. A typical GitHub Actions job:

name: API contract tests run: | npx newman run ./postman/collection.json \ -e ./postman/env.ci.json \ --reporters cli,junit \ --reporter-junit-export junit.xml Combine that with the Docker builder pattern for reproducible runners that include Newman pre-installed.

Comparison: Postman vs. alternatives

Tool GUI CLI Async webhooks Best for
Postman Yes Newman Manual polling Collaborative API exploration
Insomnia Yes inso Plugin needed Lean, scriptable workflows
Hurl No hurl Limited Plain-text, git-friendly tests
Bruno Yes bru Manual Offline-first, file-based specs
k6 No k6 Yes Load + functional combined runs
The "right" tool depends on team shape. If your QA engineers live in a GUI and your devs live in a terminal, Postman + Newman bridges both.

Troubleshooting

My webhook never arrives.
Inspect outbound calls from your service with a packet log or your provider's delivery dashboard. The most common cause is a wrong URL pasted into an environment variable.

Tests pass locally and fail in CI.
Almost always an environment file mismatch. Use newman run ... --env-var key=value to override per-run instead of editing committed JSON.

Postman scripts time out.
Default request timeout is 0 (no timeout). For polling loops set a hard deadline in script as shown above.

FAQ

Can Postman replace Cypress or Playwright?
No. Postman covers the API surface; Cypress and Playwright cover the browser. They complement each other — API tests are fast and exhaustive, UI tests are slow and selective.

Does Newman support parallel runs?
Not natively. Use newman-run-parallel or run multiple Newman processes in your CI matrix, each with a distinct collection slice.

How do I share a Postman collection without leaking secrets?
Export the collection but never the environment. Commit the collection JSON, share a sanitized env.example.json, and let each developer create their own env.local.json ignored by git.

Is there a free alternative for Postman Cloud?
The Postman desktop app is free for collections and Newman runs. Cloud features like Mock Server and Monitor are paid; for those, YoBox's Webhook Tester covers most ad-hoc needs at zero cost.

After months of building, testing, and refining, I'm excited to launch YoBox on Product Hunt!

yobox — Mon, 03 Aug 2026 16:44:00 +0000

🚀 Hey developers!

After months of building, testing, and refining, I'm excited to launch YoBox on Product Hunt!

YoBox is an all-in-one developer toolkit designed to save time by bringing the tools you use every day into one clean workspace. No ads overload, no unnecessary complexity—just fast, practical tools that help you get work done.

✨ Some of the available tools include:
• Temporary Email
• Webhook Tester
• Docker Compose Builder
• JSON Formatter & Validator
• Regex Tools
• Password Generator
• Image & File Utilities
• And many more...

I'd be honored if you could join the launch as a Maker and support the project.

👉 Accept the invitation here:
https://www.producthunt.com/posts/yobox-developer-tools-email/maker-invite?code=QN4gDN

Every maker, upvote, comment, and piece of feedback helps improve YoBox and reach more developers around the world.

Thank you so much for your support! ❤️

ProductHunt #BuildInPublic #IndieHackers #WebDevelopment #DeveloperTools #Programming #Coding #OpenSource #SaaS #Webhooks #Docker #JSON #Regex #Productivity #DevCommunity #LaunchDay #Startups #Tech

Stripe and PayPal Webhook Testing: A Practical Guide

yobox — Fri, 31 Jul 2026 16:44:35 +0000

Payment webhooks are the highest-stakes webhooks you'll ever wire up. A missed payment_intent.succeeded means a customer paid and didn't get their thing. A double-processed charge.refunded means you accidentally refunded twice. The bugs hide until they don't.

This is the practical guide to testing Stripe and PayPal webhooks end-to-end — from inspecting the raw payloads to verifying signatures, simulating failures, and asserting on the full async flow.

The Three Layers of Webhook Testing

For payment webhooks specifically:

Layer What you're testing How
Inspection What does the provider actually send? YoBox Webhook Tester, Stripe CLI
Handler logic Does my code do the right thing on a known payload? Unit tests with fixture payloads
End-to-end Does the full flow work, including signature, retries, idempotency? Integration tests against test mode
Skip any layer and bugs leak.

Layer 1: Inspect the Payloads

Before writing the handler, see what the provider sends. The docs are usually right; "usually" is a problem when money's involved.

Stripe
Use the YoBox Webhook Tester:

Generate a capture URL in YoBox.
In the Stripe dashboard → Developers → Webhooks → Add endpoint.
Paste the YoBox URL. Select the events you care about.
Use the Stripe CLI to trigger test events: stripe trigger payment_intent.succeeded.
Watch the capture log fill in.
You'll see the full payload, including:

Stripe-Signature header (the HMAC you'll verify)
Stripe-Version header
JSON body with type, data.object, etc.

Save a few payloads as test fixtures. You'll want them for unit tests.

PayPal
Same flow, but PayPal's UI is more cumbersome:

Generate a YoBox capture URL.
In the PayPal Developer dashboard → My Apps & Credentials → your app → "Add webhook."
Paste the URL. Select events.
Use the simulator: Webhook Simulator → choose event type → enter your URL.
Inspect in YoBox.
PayPal payloads are noisier than Stripe's. The signature scheme is also more complex (involves cert chain verification, not just HMAC). Capture early, save fixtures.

Layer 2: Unit Test the Handler

With fixtures in hand, write unit tests that hit your handler directly:

import paymentSucceeded from './fixtures/stripe-payment-intent-succeeded.json';

test('handles payment_intent.succeeded', async () => {
const result = await handleStripeWebhook(paymentSucceeded);
expect(result.status).toBe('processed');
expect(orderRepo.markPaid).toHaveBeenCalledWith({
orderId: paymentSucceeded.data.object.metadata.order_id,
amount: paymentSucceeded.data.object.amount,
});
});

test('is idempotent on duplicate event', async () => {
await handleStripeWebhook(paymentSucceeded);
const second = await handleStripeWebhook(paymentSucceeded);
expect(second.status).toBe('skipped-duplicate');
expect(orderRepo.markPaid).toHaveBeenCalledTimes(1);
});

test('rejects bad signature', async () => {
await expect(
handleStripeWebhook(paymentSucceeded, { signature: 'bogus' })
).rejects.toThrow(/signature/);
});

Run on every PR.

Layer 3: End-to-End in Test Mode

The most important layer and the one teams most often skip. The flow:

Spin up your app pointed at Stripe (or PayPal) test mode.
Configure the webhook endpoint to be your app's real handler URL (via ngrok in dev, your staging URL in CI).
Create a real test charge with the Stripe CLI or PayPal sandbox.
Assert on:

The webhook arrived
Your handler returned 2xx within timeout
The database state is correct
Any downstream side effects fired Using the Stripe CLI in CI

# Forward webhooks to localhost while running tests
stripe listen --forward-to http://localhost:3000/webhooks/stripe &

#Trigger a known event stripe trigger payment_intent.succeeded
Now your test asserts on the resulting state ```
{% endraw %}

The Stripe CLI handles signature verification and gives you a known webhook secret you can use in tests.

Pairing with YoBox for capture verification
Sometimes you want to assert that your app sent a webhook downstream — for example, a notification to a downstream service after the payment processed. Point that downstream URL at the YoBox Webhook Tester in test mode:
{% raw %}


```ts
test('after payment, notifies fulfillment service', async () => {
const captureUrl = 'https://yobox.dev/webhook/' + crypto.randomUUID();
await setFulfillmentWebhookUrl(captureUrl);

await triggerStripePaymentInTestMode();

const captured = await pollForWebhook(captureUrl, 30_000);
expect(captured.body.event).toBe('order.paid');
expect(captured.body.amount).toBeGreaterThan(0);
});

Signature Verification: Stripe

import Stripe from 'stripe';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

export async function POST(req: Request) {
const signature = req.headers.get('stripe-signature');
const body = await req.text(); // raw body, not parsed

let event: Stripe.Event;
try {
event = stripe.webhooks.constructEvent(
body,
signature!,
process.env.STRIPE_WEBHOOK_SECRET!
);
} catch (err) {
return new Response('invalid signature', { status: 400 });
}

// Idempotency check
if (await wasProcessed(event.id)) {
return new Response('ok', { status: 200 });
}

// Process
await processStripeEvent(event);
await markProcessed(event.id);

return new Response('ok', { status: 200 });
}

Three things to never skip:

Use the raw body. Body parsing destroys the signature.
Catch and 400 on invalid signature. Don't 500 (the provider will retry).
Idempotency by event ID. Stripe explicitly recommends this.

Signature Verification: PayPal

PayPal is more involved. You need to fetch their cert and verify the signature chain.

import { verifyPayPalWebhook } from './paypal-verify';

export async function POST(req: Request) {
const headers = {
'paypal-transmission-id': req.headers.get('paypal-transmission-id')!,
'paypal-transmission-time': req.headers.get('paypal-transmission-time')!,
'paypal-transmission-sig': req.headers.get('paypal-transmission-sig')!,
'paypal-cert-url': req.headers.get('paypal-cert-url')!,
'paypal-auth-algo': req.headers.get('paypal-auth-algo')!,
};
const body = await req.text();

const valid = await verifyPayPalWebhook({
headers,
body,
webhookId: process.env.PAYPAL_WEBHOOK_ID!,
});
if (!valid) return new Response('invalid', { status: 400 });

// ... process
return new Response('ok');
}

Use PayPal's official SDK if at all possible — implementing the verification yourself is error-prone.

Common Stripe Webhook Bugs to Test For

Missing idempotency. Same payment_intent.succeeded arrives twice, you mark the order paid twice and ship twice.
Out-of-order events. charge.refunded arrives before charge.succeeded. Your handler crashes on missing parent.
Test events processed in production. Always check event.livemode.
Body parsed before signature verified. Signature fails 100% of the time.
Slow 2xx. Stripe retries; you process duplicates.
Treating payment_intent.processing as success. It's not. Wait for succeeded.
Refund webhooks not handled. Customer disputes a charge, your DB still shows it paid.

Common PayPal Webhook Bugs

Signature verification skipped because "it's hard." Don't. Use the SDK.
Event types not mapped to product events. PayPal sends PAYMENT.CAPTURE.COMPLETED for what Stripe calls payment_intent.succeeded. Different vocabulary, same concept.
Sandbox vs live confusion. Both modes use similar URLs; check the credentials, not the URL.
Multiple webhook subscriptions firing same event twice. Audit your subscription list.

What to Test Manually

Some tests are easier to run manually in test mode than to automate:

Card decline flows. Trigger with Stripe's 4000000000000002 test card.
3DS / SCA flows. Trigger with 4000002500003155.
Dispute creation. Stripe lets you simulate disputes in the dashboard.
PayPal sandbox checkout. Use sandbox buyer accounts.
For each, capture the full webhook sequence in YoBox and turn into a test fixture.

End-to-End with Email

Most payment flows also send an email to the customer (receipt, confirmation). To test the full flow:

Sign up a test user with a YoBox Temp Mail address.
Trigger payment in Stripe test mode.
Wait for the receipt email in the temp inbox.
Wait for the webhook to fire (capture in YoBox Webhook Tester or your real handler).
Assert on database state, email body, and webhook payload.
See "Email Testing Guide for Developers" and "Webhook Testing Complete Guide" for the patterns.

FAQ

Can I test Stripe webhooks without ngrok?
Yes — use the Stripe CLI's stripe listen for local, or deploy to a staging URL. For inspection, YoBox Webhook Tester.

Why is my Stripe signature always failing?
99% of the time: body is being parsed before verification. Use raw body.

Does PayPal sign webhooks?
Yes — it's just more complex than Stripe's HMAC. Use the official SDK.

Should I unit test or integration test payment webhooks?
Both. Unit tests with fixtures for handler logic; integration tests in Stripe test mode for the full flow.

Can I replay a Stripe webhook?
Yes — from the Stripe dashboard webhook log, click "Resend." Useful for replaying after fixing handler bugs.

Bottom Line

Payment webhooks deserve more test coverage than they usually get. Inspect the real payloads with YoBox Webhook Tester, save fixtures, unit test the handler, end-to-end test in provider test mode, and never skip signature verification or idempotency. The cost of getting this right once is way lower than the cost of refunding 1,000 customers because of a duplicate-event bug.

YoBox Team

Builder behind YoBox — a privacy-first toolbox for developers and QA engineers covering disposable email, webhook capture, regex, secure passwords, Docker, and end-to-end testing.

The Only docker-compose.yml Pattern You Need (2026 Edition)

yobox — Wed, 29 Jul 2026 16:33:08 +0000

There are two kinds of docker-compose.yml files in the world: the one a developer writes in twenty minutes that works for exactly one machine, and the one a team refactors fourteen times before settling on a pattern that survives both local dev and CI. This article gives you the second one, fully formed, with the reasoning behind each section.

The YoBox Docker Builder scaffolds it; this guide explains why the lines exist.

The five jobs a good compose file does

Bring the app up locally with a single command.
Reproduce CI exactly, no surprises.
Compose nicely with sidecars (databases, caches, e2e runners).
Survive partial failures with health checks and explicit dependencies.
Stay readable when a new engineer opens it on day one.

The pattern

name: myapp

x-defaults: &defaults
restart: unless-stopped
init: true

services:
db:
<<: *defaults
image: postgres:16-alpine
environment:
POSTGRES_USER: app
POSTGRES_PASSWORD: app
POSTGRES_DB: app
volumes: ["db-data:/var/lib/postgresql/data"]
healthcheck:
test: ["CMD-SHELL", "pg_isready -U app -d app"]
interval: 5s
timeout: 3s
retries: 20

redis:
<<: *defaults
image: redis:7-alpine
healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 5s
timeout: 3s
retries: 10

api:
<<: *defaults
build: ./api
environment:
DATABASE_URL: postgres://app:app@db:5432/app
REDIS_URL: redis://redis:6379
YOBOX: https://yobox.dev/api
depends_on:
db: { condition: service_healthy }
redis: { condition: service_healthy }
ports: ["3000:3000"]
healthcheck:
test: ["CMD", "wget", "-qO-", "http://localhost:3000/health"]
interval: 5s
timeout: 3s
retries: 30

web:
<<: *defaults
build: ./web
environment:
API_URL: http://api:3000
depends_on:
api: { condition: service_healthy }
ports: ["8080:80"]

e2e:
profiles: ["test"]
build: ./tests
environment:
BASE_URL: http://web:80
YOBOX: https://yobox.dev/api
depends_on:
web: { condition: service_started }
api: { condition: service_healthy }

volumes:
db-data:

That's it. Eighty lines that handle local dev, CI e2e, sidecar databases, health-checked dependencies, and a profile gate so docker compose up doesn't pull in the test runner unless you ask.

Why each section matters

x-defaults anchor
YAML anchors are the single most underused feature of compose. They eliminate the restart / init boilerplate that otherwise drifts between services.

Health checks on everything
depends_on: [db] without condition: service_healthy only guarantees the container started — not that Postgres is accepting connections. The retries-with-interval pattern above prevents the race condition that makes 5% of your CI runs go red.

Profiles for test-only services
profiles: ["test"] keeps e2e out of normal up invocations. Run with docker compose --profile test up.

YoBox over the public network
The e2e service hits https://yobox.dev/api directly. That keeps the compose file simple — no mail server, no webhook tunnel, no extra sidecar. The same compose file runs identically on a laptop, in GitHub Actions, and on a self-hosted runner.

Local dev workflow

docker compose up -d
docker compose logs -f api
When you change application code in a bind-mounted volume, restart just one service:

CI workflow

run: docker compose --profile test up --build --abort-on-container-exit --exit-code-from e2e --abort-on-container-exit stops everything as soon as e2e finishes. --exit-code-from e2e propagates the test runner's exit code to the workflow.

Comparison: common patterns

Pattern Pros Cons
One compose, one machine Trivial Doesn't survive CI
Multiple compose files (-f) Maximum flexibility Easy to drift, hard to onboard
Profiles + healthchecks (this) One file, two modes, deterministic deps Slightly more upfront thought

Pairs with

Docker Builder for Cypress & Playwright CI for the test-runner Dockerfile.
Cypress + YoBox and Playwright + YoBox for the test patterns running inside e2e.

Common pitfalls

No healthchecks. Race conditions on slow CI runners are the most common e2e flake.
Bind-mounting node_modules. Native modules differ between host and container — keep node_modules inside the image.
Forgetting init: true. Without it, Node child processes don't get reaped, leading to zombie PIDs in long runs.
Putting secrets in the compose file. Use env_file: and a .gitignored .env.

FAQ

Should I use docker-compose (v1) or docker compose (v2)?
v2. It's the supported version and the syntax above targets it.

Do I need a version: key at the top?
No — it's been ignored since v2. Leaving it out is cleaner.

Can I run this on ARM?
All the images above publish multi-arch tags. Yes.

Where do volumes go in production?
This pattern is for dev and CI. Production uses managed Postgres, managed Redis, and Kubernetes or Fly — not compose.

Conclusion

One compose file. Two modes (up and --profile test up). Healthchecks on everything, anchors for shared defaults, and YoBox over the public internet so your e2e suite has real inboxes and real webhook capture without any sidecar gymnastics. Generate the starting skeleton from the Docker Builder and customize from there.

See also: Docker Builder for Cypress & Playwright CI, Cypress + YoBox, Playwright + YoBox.

Advanced: \develop.watch\ for hot reload

Compose v2.22+ ships \develop.watch\ — file-system events that sync source into a container and trigger a restart. Replaces \docker compose up\ plus a \nodemon\ sidecar with a single declarative block.

Resource limits in CI

Add \deploy.resources.limits\ to keep noisy services from starving the e2e runner. Especially important on GHA runners where 7 GB is the hard ceiling.

Secrets

Use Docker secrets for anything sensitive. They mount as files inside \/run/secrets\ rather than appearing in \docker inspect.

Migration: from a sprawling Makefile

Most teams arrive at a clean compose file by replacing a 200-line Makefile. The transition is mechanical: each Make target becomes either a service, a profile, or a \run --rm\ invocation.

CI invocation reference

\docker compose --profile test up --build --abort-on-container-exit --exit-code-from e2e\ is the one-liner. Add --quiet-pull\ in CI to suppress noise.

The pattern, restated

One docker-compose.yml per repo. Services named after what they do, not where they came from. Volumes for state, networks only when you need isolation, and a .env file for everything that differs between developers. That's it. Anything more is premature.

services:
app:
build: .
env_file: .env
ports: ["3000:3000"]
depends_on: [db, redis]
db:
image: postgres:16-alpine
environment:
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
volumes: ["pgdata:/var/lib/postgresql/data"]
redis:
image: redis:7-alpine
volumes:
pgdata:
Five services, three lines of volumes, zero networks. If a new contributor can't run docker compose up and get a working app, the file is wrong, not them.

Profiles for optional services

Compose profiles let you keep heavy or optional services in the same file without forcing every developer to run them.

services:
mailhog:
image: mailhog/mailhog
profiles: ["email"]
jaeger:
image: jaegertracing/all-in-one
profiles: ["tracing"]
docker compose --profile email up starts MailHog only when needed. For real inbox testing without MailHog, point your app at YoBox Temp Mail and skip the local SMTP stack entirely.

Healthchecks that actually matter

depends_on only waits for container start, not readiness. Add a healthcheck so app waits for Postgres to accept connections:

db:
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 2s
timeout: 2s
retries: 20
app:
depends_on:
db: { condition: service_healthy }

Bind mounts vs. named volumes

Use case Mount type Why
Source code (live reload) Bind Edit on host, run in container
Database files Named volume Docker manages permissions and lifecycle
Shared between dev + CI Named volume Same image, no host-path surprises
One-off seed data Bind (:ro) Reproducible, version-controlled
The biggest source of "works on my machine" is bind-mounting a directory that contains files created by the container as root.

Production parity

The same compose file should not be your production deployment. The pattern is:

docker-compose.yml — local dev, with bind mounts and dev images.
docker-compose.ci.yml — overrides for CI: no bind mounts, deterministic seeds.
Production runs on Kubernetes, ECS, Fly, or Render — translated from compose by hand or with tools like kompose.
Trying to make compose your prod runtime is the road to a custom orchestrator built out of bash.

CI usage

In GitHub Actions:

run: docker compose -f docker-compose.yml -f docker-compose.ci.yml up -d
run: docker compose exec -T app npm test
run: docker compose down -v Pair with the Docker builder for Cypress and Playwright CI when you need browsers inside the same compose graph.

Troubleshooting

Port already in use.
Either another compose stack is running (docker compose ls) or a host process owns the port. Change the host side: "3001:3000".

Database loses data between runs.
You're using a bind mount on a path that gets cleaned, or you're running docker compose down -v. Use named volumes and avoid -v unless you mean it.

Image rebuilds take forever.
Add a .dockerignore to exclude node_modules, .git, and build artifacts. Order Dockerfile instructions so dependencies are cached above source.

FAQ

Should I use Docker Compose v1 or v2?
v2 — it's the official Docker CLI plugin. docker compose (space, not dash) is the current command.

Can I run multiple compose files together?
Yes, with -f base.yml -f override.yml. Later files override earlier ones key-by-key.

How do secrets work in compose?
Use env_file for dev, secret managers for prod. Don't commit .env. The secrets: block exists but is mostly relevant for Swarm.

Is compose dead?
No. It remains the best tool for local dev parity. Kubernetes is for production; compose is for the developer loop.

How does this fit with the YoBox Docker Builder?
The Docker Builder generates the kind of opinionated Dockerfile that plugs into the compose pattern above — node/python/go templates, multistage builds, and a sane default user.

YoBox Team

Builder behind YoBox — a privacy-first toolbox for developers and QA engineers covering disposable email, webhook capture, regex, secure passwords, Docker, and end-to-end testing.

I Built a Temp Mail & Webhook Tool — Reddit Instantly Thought I Was a Spammer

yobox — Mon, 27 Jul 2026 16:21:32 +0000

I spent the better part of two weeks living on caffeine, error logs, and the kind of optimism only a solo developer at 3 AM can produce. The goal was simple, or at least it sounded simple when I wrote it on a sticky note: build a clean, fast, free developer toolbox. No signups. No dark patterns. No "upgrade to Pro to copy your own output."

I called it YoBox — a single home for the small tools developers and QA engineers reach for every day: disposable email, webhook capture, Docker Compose scaffolding, regex testing, password generation, and Lorem Ipsum that doesn't look like it was generated in 2008.

Then I launched it on Reddit.

Reddit, in its infinite wisdom, decided I was a spam bot operating out of an undisclosed bunker.

This is the story of how that happened, what I learned, and why I now have more respect for spam filters than I ever wanted to have.

The Infrastructure Battle

Before any of the funny parts, there was the unfunny part: the infrastructure.

Domain, DNS, and the Cloudflare Dance
I bought yobox.dev on a whim because it was short, memorable, and ended in .dev — which forces HTTPS by default and feels appropriately nerdy. Then came Cloudflare: nameservers, proxy toggles, SSL modes, page rules, and the perennial question of whether "Full (strict)" is going to make my site work or break it in a way that's invisible until a user complains.

DNS is the only system on Earth where you make a change, wait 24 hours, and then find out you typed one character wrong.

GitHub, Render, and the API Backend
The frontend lives as a Vite + React app. The backend is a small Node/Express service deployed on Render, sitting behind the same Cloudflare proxy. Setting that up was its own small adventure:

Configuring render.yaml so the backend builds from the backend/ directory of the monorepo.
Wiring environment variables for allowed origins.
Getting CORS to actually behave — which, if you have ever fought CORS, you know is a spiritual journey, not a configuration task.
Adding a /health endpoint so Render stops killing my service every five minutes.
The Temporary Email System
The Temp Mail tool proxies a disposable inbox API through my backend so the frontend never has to expose tokens or worry about third-party CORS. It supports rotating addresses, polling for new messages every few seconds, and reading message bodies inline.

This part alone took longer than I expected. Email is a deceptively complex domain. "Just give me a throwaway inbox" turns into "okay but how do we handle token refresh, expired accounts, attachment rendering, and HTML emails that try to load tracking pixels?"

The Webhook Capture Service
The Webhook Tester was the part I was most excited about. You generate a unique URL, point any service at it, and watch requests arrive in real time — method, headers, query string, body, timestamps. Perfect for debugging Stripe events, GitHub Actions, Zapier flows, or any of the dozen other integrations that fail silently because you can't see what they're sending.

Building it required a small in-memory store, a capture middleware, and a polling endpoint so the frontend can show new requests without WebSockets (Render free tier and persistent connections are not friends).

The Moment Everything Finally Worked

There's a specific kind of joy you only feel after fighting infrastructure for days.

I opened the Temp Mail page, generated a new inbox, pasted the address into a SaaS signup form, and hit submit. Five seconds later, the OTP email appeared in my polling UI. I clicked it open. The 6-digit code was right there, ready to be copied.

Then I opened the Webhook Tester in another tab, generated a URL, and pointed a curl -X POST at it from my terminal with a JSON payload. The request showed up in the UI before I could alt-tab back. Headers, body, IP, everything.

I sat there grinning at my laptop like an idiot. The thing worked. The thing actually worked.

I deserved a launch.

Then Came Reddit...

Continue Reading

This article is part of the YoBox Developer Blog.

Read the complete guide here:

https://yobox.dev/blog/reddit-thought-i-was-a-spammer

⭐ More developer tools:
https://yobox.dev

⭐ GitHub examples:
https://github.com/hocineman4/yobox-examples

About YoBox

YoBox is a collection of free developer tools for API testing, disposable email, webhook inspection, Docker utilities, regex testing, password generation, and QA workflows.

🌐 https://yobox.dev

⭐ GitHub Examples

https://github.com/hocineman4/yobox-examples

Best Free Webhook Testing Tools (and Which One to Pick)

yobox — Sun, 26 Jul 2026 16:51:36 +0000

If you've ever Googled "webhook tester," you've seen the same five blue links for years. Most of them work. A few of them are genuinely good. And exactly zero are documented in a way that helps you pick the right one for your use case.

This is the no-nonsense list. Every tool below is free, currently maintained as of 2026, and used by real teams. We'll cover what each one is best at, the pattern it fits, and where it falls short.

The Six Tools That Matter

YoBox Webhook Tester — for fast, scriptable, no-signup capture
Webhook.site — for general-purpose inspection with custom responses
ngrok — for forwarding to a real local server
localtunnel — open-source ngrok alternative
Beeceptor — for mocking and inspecting together
Pipedream RequestBin — for triggering workflows on capture

Picking the Right One

The fastest decision path:

"I just want to see what's hitting me." → YoBox Webhook Tester or Webhook.site
"I need to test my own code running on localhost." → ngrok or localtunnel
"I need to mock an API that calls back to me." → Beeceptor
"I want to fan out captured webhooks into Zapier-like workflows." → Pipedream RequestBin
"I want all of this from inside a Cypress / Playwright test." → YoBox Webhook Tester (API-first by design)

1. YoBox Webhook Tester

The YoBox Webhook Tester is the tool we built because every other free option had a catch — ads, signup walls, retention limits, or no API for CI use.

Strengths:

No signup, no tracking, no ads
URL generates in under a second
Live request log in the browser
JSON API for automation
Pairs with YoBox Temp Mail for full async testing

Limitations:

No custom response templating yet (returns a fixed 200)
No team / sharing features beyond the URL itself

Use it when: you want a clean, fast capture tool you can also script.

2. Webhook.site

The Swiss Army knife. Custom response builder with templating, CLI forwarder, OSS self-host option, generous free tier.

Strengths:

Templated custom responses (return any status, body, headers, even delays)
Self-hostable
7-day free retention
Shareable URLs

Limitations:

URL is guessable
Ads on the free tier are non-existent (one of the cleaner free experiences, actually)
API requires signup for higher limits

Use it when: you need templated responses or self-hosting.

3. ngrok

Not a webhook tester in the same sense — ngrok creates a tunnel from a public URL to a local port, so providers can call back to code running on your laptop.

Strengths:

Real local handler development
Built-in traffic inspector at localhost:4040
Replay captured requests
TCP / TLS tunnels too, not just HTTP

Limitations:

Free URLs rotate on restart
Requires running a local server
Not designed for headless / CI use

Use it when: you're developing your own handler locally and want providers to reach it.

4. localtunnel

Open-source alternative to ngrok. Less polished, but free and stable enough for casual use.

Strengths:

Open source
Free, no signup
Custom subdomain support

Limitations:

Less reliable than ngrok
No built-in inspector

Use it when: you want ngrok-like tunneling without the ngrok account.

5. Beeceptor

Mock-first, capture as a bonus. Define endpoints with rules and responses; incoming requests get logged.

Strengths:

Powerful mocking rules (pattern-match request, return canned response)
Custom subdomain
Good for simulating third-party APIs

Limitations:

50 requests/day free
More mocking than capture

Use it when: you're mocking an API that calls back to your handler.

6. Pipedream RequestBin

The reborn RequestBin, integrated into Pipedream. Capture + workflow trigger.

Strengths:

Webhook capture triggers Pipedream workflows
Massive integration library
Generous free tier

Limitations:

Standalone capture is awkward (you're really using it as a workflow trigger)
Tied to Pipedream account

Use it when: you want incoming webhooks to do something (Slack notify, write to a sheet, fire another API).

What "Free" Actually Means

Each tool's free tier has trade-offs. Quick reality check:

Tool Free retention Free API Free team features
YoBox Webhook Tester Token lifetime (hours) Yes URL sharing
Webhook.site 7 days Limited URL sharing
ngrok Live only N/A None
localtunnel Live only N/A None
Beeceptor 50 req/day Yes None
Pipedream Workflow-tied Yes Workflow shares
For most individual use cases, the free tiers are enough. Pro tiers exist for teams with persistent URLs, SSO, and SOC 2 requirements.

Patterns That Pair With Each Tool

A webhook tester is rarely the only thing in your testing setup. Here's what each pairs with:

YoBox Webhook Tester + YoBox Temp Mail → full async signup flow testing in CI. See "Email Testing Guide for Developers".
Webhook.site + Stripe CLI → fast iteration on Stripe webhook handlers.
ngrok + your local Node/Python server → real local development.
Beeceptor + Postman → mock the API, drive Postman against the mock, verify your handler.
Pipedream + Slack → "DM me when a customer hits this webhook."

A CI Pattern You Can Steal

`ts test('signup fires both email and webhook', async ({ request }) => { // 1. Disposable inbox const inbox = await fetch('https://yobox.dev/mail/account', { method: 'POST', body: JSON.stringify({ address: t-${Date.now()}@yobox-test.dev, password: 'x' }),
headers: { 'content-type': 'application/json' },
}).then(r => r.json());

// 2. Webhook capture URL
const captureUrl = 'https://yobox.dev/webhook/' + crypto.randomUUID();

// 3. Configure your app
await configureApp({ webhookUrl: captureUrl });

// 4. Trigger signup
await request.post('/signup', { data: { email: inbox.address } });

// 5. Assert email arrived
const message = await pollForEmail(inbox.token);
expect(message.text).toMatch(/welcome/i);

// 6. Assert webhook fired
const captured = await pollForWebhook(captureUrl);
expect(captured.body.event).toBe('user.created');
});
`

FAQ

Are any of these tools paid?
All have free tiers. Webhook.site, Beeceptor, ngrok, and Pipedream have paid tiers for teams. YoBox is free.

Which one has the best browser UI?
Subjective. YoBox and Webhook.site are both clean and modern. ngrok's inspector is functional but dated.

Can I use these in production?
No. These are for testing. Production webhooks should hit your own infrastructure with persistence and retries.

Do they support WebSocket capture?
Mostly no. WebSocket capture is a separate category — Webhook.site has some support; others are HTTP-only.

Which works without a signup?
YoBox Webhook Tester, Webhook.site (for capture), localtunnel.

Bottom Line

The right tool depends on the job. For most developers in 2026: YoBox Webhook Tester covers fast capture + CI automation, ngrok covers local-handler dev, and Webhook.site covers the long tail of "I need a feature ngrok and YoBox don't have." Three free tools, full coverage. Stop reinventing your testing setup every time you start a new project.

YoBox Team

Builder behind YoBox — a privacy-first toolbox for developers and QA engineers covering disposable email, webhook capture, regex, secure passwords, Docker, and end-to-end testing.

The Complete Cypress + YoBox Guide (2026)

yobox — Sat, 25 Jul 2026 16:33:54 +0000

Cypress is still one of the fastest ways to ship a trustworthy end-to-end test suite in 2026. It runs in a real browser, gives you time-travel debugging, and the API reads like English. The piece most teams still get wrong isn't Cypress itself — it's everything around the test: provisioning a fresh email account for each run, capturing the OTP, asserting that a webhook actually fired, and doing all of it without depending on a shared mailbox or a tunneling tool that breaks every other Tuesday.

That's exactly the gap YoBox was built to close. This guide walks through a complete Cypress + YoBox setup — from your first cy.task helper to a parallel-safe pipeline that signs up real users, reads real OTP emails, and verifies real webhook payloads.

Why pair Cypress with YoBox

Most signup, password-reset, magic-link, and billing flows depend on two external systems your tests can't fake: an inbox and an HTTP receiver. Stub them and you stop testing the thing that actually breaks in production. Use a shared dev inbox and your suite goes flaky the moment you parallelize.

YoBox gives every test:

A disposable inbox with a unique address, provisioned in milliseconds.
A unique webhook URL that records every request — headers, body, query string, timestamp.
Plain HTTP endpoints, no SDK, no auth tokens, no rate-limit ceremony.
Pair that with Cypress's deterministic command queue and retries, and you get a suite that can run 50-wide in CI without a single shared resource.

Project setup

Install Cypress and a tiny waiting helper:

npm i -D cypress cypress-wait-until
In cypress/support/e2e.js:

import "cypress-wait-until";
Add the YoBox base URL as an env var so you can point at staging or production:

// cypress.config.js
module.exports = {
e2e: {
baseUrl: "https://app.yourproduct.com",
env: { YOBOX: "https://yobox.dev/api" },
setupNodeEvents(on) {
on("task", {
async newInbox() {
const r = await fetch(${process.env.YOBOX}/mail/new, { method: "POST" });
return r.json();
},
async readInbox(id) {
const r = await fetch(${process.env.YOBOX}/mail/${id}/messages);
return r.json();
},
async newHook() {
const r = await fetch(${process.env.YOBOX}/hooks/new, { method: "POST" });
return r.json();
},
async readHook(id) {
const r = await fetch(${process.env.YOBOX}/hooks/${id});
return r.json();
},
});
},
},
};

Signup + OTP in a single spec

This is the flow that breaks first when teams stub email. Don't stub it. Use a real disposable inbox.

// cypress/e2e/signup-otp.cy.js
describe("Signup with email OTP", () => {
it("creates an account end-to-end", () => {
cy.task("newInbox").then((inbox) => {
cy.visit("/signup");
cy.get("input[name=email]").type(inbox.address);
cy.get("input[name=password]").type("Sup3rSecret!2026");
cy.get("button[type=submit]").click();

cy.waitUntil(
() =>
cy.task("readInbox", inbox.id).then((d) => d.messages?.length >= 1),
{ timeout: 30000, interval: 1500 }
);

cy.task("readInbox", inbox.id).then((data) => {
const otp = data.messages[0].text.match(/\b\d{6}\b/)[0];
cy.get("input[name=otp]").type(otp);
cy.contains("Verify").click();
cy.url().should("include", "/welcome");
});
});
});
});

That's an honest end-to-end test: a unique email, a real SMTP delivery, a real OTP, and a real verification screen.

Webhook assertions without ngrok

Stripe, GitHub, Shopify, Twilio — every modern backend talks via webhooks, and every developer has lost an afternoon to "is my webhook even firing?" YoBox's Webhook Tester gives you a URL that captures everything and exposes it over a plain JSON endpoint Cypress can poll.

it("billing event triggers downstream webhook", () => {
cy.task("newHook").then((hook) => {
cy.visit("/admin/billing");
cy.contains("Send test event").click();
cy.get("input[name=callback]").clear().type(hook.url);
cy.contains("Fire").click();

cy.waitUntil(() =>
cy.task("readHook", hook.id).then((d) => d.count >= 1)
);

cy.task("readHook", hook.id).then((data) => {
const req = data.requests[0];
expect(req.method).to.eq("POST");
expect(req.headers["content-type"]).to.match(/json/);
expect(JSON.parse(req.body)).to.have.property("event", "invoice.paid");
});
});
});

You're not just asserting that something fired — you're asserting the shape of the payload, which is the part that actually regresses.

Parallel-safe by default

Cypress parallelization fails the moment two workers share a mailbox or a webhook URL. With YoBox, every cy.task("newInbox") returns an isolated resource, so a 12-shard build is the same as a single-shard build — minus 11x the wall-clock time.

Resource Shared dev inbox YoBox per-test inbox
Parallel-safe No Yes
Setup cost Manual One HTTP call
OTP collision risk High Zero
CI cleanup Manual Auto-expires

Realistic data helpers

................

Continue Reading

This article is part of the YoBox Developer Blog.

Read the complete guide here:

https://yobox.dev/blog/cypress-guide

⭐ More developer tools:
https://yobox.dev

⭐ GitHub examples:
https://github.com/hocineman4/yobox-examples

About YoBox

YoBox is a collection of free developer tools for API testing, disposable email, webhook inspection, Docker utilities, regex testing, password generation, and QA workflows.

🌐 https://yobox.dev

⭐ GitHub Examples

https://github.com/hocineman4/yobox-examples

Generating Cryptographically Secure Passwords in the Browser

yobox — Fri, 24 Jul 2026 18:21:43 +0000

The most common mistake in homemade password generators is also the most invisible: using Math.random(). It looks random. It feels random. It is not random — at least not in any sense a security auditor or attacker cares about. This article explains why, walks through the right primitive (Web Crypto's getRandomValues), and builds a complete password generator like the one powering the YoBox Password Generator.

The problem with Math.random

Math.random() returns a double in [0, 1). Under the hood it's a pseudo-random number generator — a deterministic algorithm seeded once per page load. Given enough output, the internal state can be reconstructed, and from there every future "random" number is predictable. There are published papers on doing exactly that against V8 and SpiderMonkey.

For animations, particle effects, or shuffling a list of cat photos, that's fine. For passwords, encryption keys, session tokens, or anything an attacker cares about, it's malpractice.

The right primitive

Every modern browser ships Web Crypto. The relevant function is crypto.getRandomValues:

const buf = new Uint8Array(20);
crypto.getRandomValues(buf);
It fills the typed array with cryptographically secure random bytes drawn from the OS entropy source. On Linux that's /dev/urandom; on macOS, SecRandomCopyBytes; on Windows, BCryptGenRandom. All three are fit for keying material.

Mapping bytes to a charset

The naive approach has a subtle bias bug:

// Slight modulo bias — avoid in production
const c = charset[buf[i] % charset.length];
If charset.length doesn't evenly divide 256, the early characters in the charset are slightly more likely. For a 62-char alphanumeric set the bias is negligible; for a 70-char set with symbols it's measurable. The unbiased version rejects bytes above the largest multiple of charset.length:

function pickChar(charset: string): string {
const max = Math.floor(256 / charset.length) * charset.length;
while (true) {
const b = crypto.getRandomValues(new Uint8Array(1))[0];
if (b < max) return charset[b % charset.length];
}
}
For most production purposes, fetching a larger buffer and rejecting biased bytes in a single pass is more efficient:

export function generatePassword(length = 20, charset = DEFAULT_CHARSET) {
const max = Math.floor(256 / charset.length) * charset.length;
const out: string[] = [];
while (out.length < length) {
const buf = crypto.getRandomValues(new Uint8Array(length * 2));
for (const b of buf) {
if (out.length >= length) break;
if (b < max) out.push(charset[b % charset.length]);
}
}
return out.join("");
}

Choosing a charset

A pragmatic default:

const DEFAULT_CHARSET =
"ABCDEFGHJKMNPQRSTUVWXYZ" + // no I, L, O
"abcdefghjkmnpqrstuvwxyz" + // no i, l, o
"23456789" + // no 0, 1
"!@#$%^&*-_=+";
Excluding visually ambiguous characters (0/O, 1/l/I) is the difference between "this works in a screenshot handoff" and "support ticket every Tuesday."

Enforcing complexity rules

Some systems require at least one of each character class. The cleanest pattern is to draw one from each required class, then fill the rest from the union, then shuffle:

export function generateWithClasses(length = 20) {
const classes = [
"ABCDEFGHJKMNPQRSTUVWXYZ",
"abcdefghjkmnpqrstuvwxyz",
"23456789",
"!@#$%^&*-_=+",
];
const required = classes.map((c) => pickChar(c));
const rest = Array.from({ length: length - required.length }, () =>
pickChar(classes.join(""))
);
return shuffle([...required, ...rest]).join("");
}

function shuffle<T>(arr: T[]): T[] {
// Fisher–Yates with crypto-grade randomness
for (let i = arr.length - 1; i > 0; i--) {
const buf = crypto.getRandomValues(new Uint32Array(1));
const j = buf[0] % (i + 1);
[arr[i], arr[j]] = [arr[j], arr[i]];
}
return arr;
}

Entropy: how strong is "strong"?
...............

Continue Reading

This article is part of the YoBox Developer Blog.

Read the complete guide here:

https://yobox.dev/blog/generating-cryptographically-secure-passwords-in-the-browser

⭐ More developer tools:
https://yobox.dev

⭐ GitHub examples:
https://github.com/hocineman4/yobox-examples

About YoBox

YoBox is a collection of free developer tools for API testing, disposable email, webhook inspection, Docker utilities, regex testing, password generation, and QA workflows.

🌐 https://yobox.dev

⭐ GitHub Examples

https://github.com/hocineman4/yobox-examples

Frontend-Only SaaS: The Rise of Static Utility Sites

yobox — Thu, 23 Jul 2026 17:40:50 +0000

Frontend-Only SaaS

The combination of fast browser APIs (Web Crypto, Workers, WebAssembly) and generous third-party APIs (mail.gw, webhook.site) means you can ship serious developer tooling with zero backend.

What you save

Servers — no Node process to scale.
Databases — localStorage covers user-scoped state.
Auth — for utility tools, often unnecessary.

What you lose

Centralized analytics, multi-device sync, abuse rate-limiting. Add them only when the tool is popular enough to need them.
YoBox itself is now a pure static SPA — built with Vite, hosted on any $5/month shared host.

Why frontend-only SaaS is suddenly viable

Five years ago, "frontend-only SaaS" meant a glorified landing page that funneled signups into a real backend. In 2026 the browser is a legitimate runtime. Web Crypto generates audit-grade entropy, Web Workers offload heavy parsing, WebAssembly runs image and video pipelines at near-native speed, and IndexedDB stores gigabytes per origin. Combine those with a handful of generous public APIs — disposable email providers, webhook capture services, public AI gateways — and an entire class of developer tooling no longer needs a server at all.

YoBox is one example. The Temp Mail, Webhook Tester, Password Generator, Regex Assistant, and Lorem / Mock Data tools all run inside the user's tab. The "backend" is a thin Express service that exists only to proxy a single third-party API and serve a /health endpoint. The same product pattern powers dozens of indie tools — JSON formatters, JWT decoders, UUID generators, cron explainers, color pickers — that collectively serve millions of requests per month from a static bucket.

A frontend-only SaaS is not a "lesser" SaaS. It is a SaaS whose unit economics survive being free.

What you actually save

Servers
There is no Node process to scale, no autoscaling group to tune, no cold-start penalty, no 3 AM PagerDuty alert because someone deployed a memory leak. A static CDN serves index.html and a few hashed JS bundles. The marginal cost of the millionth visitor is a fraction of a cent.

Databases
localStorage, sessionStorage, and IndexedDB cover the entire surface area of "user-scoped state" for a utility tool. Preferences, history, saved snippets, generated tokens — all of it lives in the browser. You get per-user isolation for free, you never run a migration, and GDPR compliance becomes a one-line privacy policy: "We don't store your data."

Auth
For a tool that generates a password or captures a webhook, asking the user to sign up is a hostile act. No auth means no password reset emails, no OAuth provider outages, no session fixation bugs, no "forgot password" flow to maintain. The tool just works, in an incognito window, behind a corporate proxy, on a stranger's laptop at a conference.

Compliance overhead
No PII at rest means no SOC 2 audit, no DPA negotiation, no data residency conversation. You can ship to EU customers on day one without legal review.

What you give up

Open
Capability Frontend-only Traditional SaaS
Cross-device sync Manual export/import Built-in
Centralized analytics Privacy-friendly aggregates only Full per-user funnel
Abuse rate-limiting Edge / CDN only Per-account quotas
Long-running jobs None — tab must stay open Queue + worker
Server-side secrets None — everything is public Vault-backed
Team features Awkward Native
The honest framing: frontend-only is the right default for utility tools, and the wrong default for collaboration tools. If two users need to see the same state, you need a server.

Architecture patterns that make it work

The "thin proxy" backend
Most "frontend-only" products still ship a tiny backend — but it does exactly one thing: hide an API key or bypass CORS. The proxy never stores data, never authenticates users, and never grows past ~200 lines of code. The pattern in the Docker Builder Guide — a single Dockerfile, one /health endpoint, deployed to a $5/month box — is enough.

Public APIs as a backplane
Disposable email, webhook capture, public LLM gateways, and IP geolocation APIs all expose enough surface area to build a real product on. The risk is provider lock-in; the mitigation is an adapter layer so swapping mail.gw for mailisk is a one-file change.

Web Workers for anything expensive
Parsing a 50 MB JSON file, running a regex over a million lines, or hashing a password 100,000 times — all of it belongs in a Worker. The main thread stays responsive, the UI never jank-freezes, and Lighthouse scores stay green.

IndexedDB for "real" persistence
localStorage is synchronous and capped at ~5 MB. IndexedDB is asynchronous, structured, and effectively unlimited. For any tool that saves user data, default to IndexedDB through a wrapper like idb-keyval or Dexie.

Real use cases

...........

Continue Reading

This article is part of the YoBox Developer Blog.

Read the complete guide here:

https://yobox.dev/blog/testing-apis-with-postman-yobox-2026-workflow

⭐ More developer tools:
https://yobox.dev

⭐ GitHub examples:
https://github.com/hocineman4/yobox-examples

About YoBox

YoBox is a collection of free developer tools for API testing, disposable email, webhook inspection, Docker utilities, regex testing, password generation, and QA workflows.

🌐 https://yobox.dev

⭐ GitHub Examples

https://github.com/hocineman4/yobox-examples

Tailwind v4: The Features Actually Worth Migrating For

yobox — Wed, 22 Jul 2026 17:29:34 +0000

Tailwind v4

The v4 release isn't a face-lift — it's a rewrite. Here's what actually matters.

Real wins

CSS-first config. @theme blocks replace tailwind.config.js. Tokens become real CSS custom properties.
Rust-powered engine. Build times for large apps drop from seconds to milliseconds.
Container queries built-in. No plugin.

What stays the same

Utility class names, JIT behavior, and PurgeCSS-style tree-shaking all work exactly as before. Most migrations are a config rename.

Why v4 is a rewrite, not a refresh

Tailwind v4 is the first version where the engine itself is new. The Oxide engine — written in Rust — replaces the JavaScript pipeline that has powered every previous release. The config story is new. The plugin model is new. The way themes propagate into CSS is new. If you only read the changelog you might think it is incremental; if you actually open a v4 project, the developer experience feels like a different product.

That is also why the migration question matters. Most teams should not migrate immediately. Most teams should migrate within a year. This article is the honest decision guide.

v4 is not "v3 with a new logo." It is what Tailwind would look like if it were designed in 2026 from scratch — and that is both the reason to migrate and the reason to plan the migration carefully.

The features actually worth migrating for

CSS-first configuration
tailwind.config.js is gone. Tokens, screens, fonts, and custom utilities live in CSS via @theme:

@import "tailwindcss";

@theme {
--color-brand: oklch(0.72 0.16 250);
--font-display: "Inter Tight", sans-serif;
--breakpoint-3xl: 120rem;
}

Two things change. First, your design tokens are now real CSS custom properties — usable outside Tailwind utilities, in inline styles, in arbitrary values, and in JS via getComputedStyle. Second, the config is colocated with the styles that use it, which removes an entire category of "did I rebuild after editing the config?" bugs.

The Oxide engine
Build times on a 200-component app drop from ~800 ms to ~40 ms on a warm cache. Cold builds drop from seconds to hundreds of milliseconds. On large monorepos the difference is the difference between "Tailwind is fine" and "Tailwind is invisible." If you ship a design system across many apps, this alone justifies the migration.

Native container queries
@container queries are first-class — no plugin, no preset:

...

Combined with the new @min- and @max- variants, the awkward pattern of "media queries pretending to be component queries" finally retires.

Dynamic utility values
Any number works without configuring it:

...

v3 already supported arbitrary values; v4 makes them feel native by removing the JIT-vs-bracket distinction and unifying parsing.

Better dark-mode and theming

Free tool

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

What stays the same

Utility class names are stable. flex, grid, text-sm, bg-red-500 — all unchanged. Most templates compile under v4 without any HTML edits. Plugin authors must update; consumers usually do not.

Comparison: v3 vs. v4 at a glance

Concern v3 v4
Config tailwind.config.js @theme in CSS
Engine PostCSS / JS Rust (Oxide)
Cold build (200 cmp) 1.8 s 0.2 s
Container queries Plugin Built-in
Design tokens JS object CSS custom properties
Plugin API JS CSS + JS (smaller surface)
Migration risk n/a Plugin compat, custom presets
The migration cost is mostly in plugins, not templates. Audit your plugin list first; that is where the work is.

Migration strategy

..............

Continue Reading

This article is part of the YoBox Developer Blog.

Read the complete guide here:

https://yobox.dev/blog/testing-apis-with-postman-yobox-2026-workflow

⭐ More developer tools:
https://yobox.dev

⭐ GitHub examples:
https://github.com/hocineman4/yobox-examples

About YoBox

YoBox is a collection of free developer tools for API testing, disposable email, webhook inspection, Docker utilities, regex testing, password generation, and QA workflows.

🌐 https://yobox.dev

⭐ GitHub Examples

https://github.com/hocineman4/yobox-examples

DEV Community: yobox

Why OTP Verification Fails (and How to Fix It)

1. The Code Already Expired

2. The Code Was Already Used

3. The Email Was Silently Rejected

4. The Email Went to a Spam Folder You Can't See

5. You're Verifying With the Wrong Address

6. The Site's Clock Is Wrong

7. Rate Limiting

How to Diagnose, in Order

OTP Best Practices for Developers

A Minimal Test Loop

OTP vs Magic Links

FAQ

Bottom Line

YoBox Team

Temporary Email for Developers: The Definitive Guide

What Developers Actually Use Temp Mail For

The Developer Toolkit

Pattern 1: Testing Your Own Signup Flow

Pattern 2: E2E Tests in CI

Pattern 3: Pair with Webhook Capture

Pattern 4: OAuth Provider Testing

Pattern 5: Beta / Trial Accounts

Pattern 6: Bot / Service Accounts

Reducing Inbox Spam

What to Build Into Your Dotfiles

Security Reminders

FAQ

Bottom Line

YoBox Team

Testing API Responses Seamlessly with Postman and YoBox

The mental model

Setting up the environment

Asserting response shape

Asserting email side effects

Asserting webhook side effects

Comparison table

Running in CI

Pairs with

Common pitfalls

FAQ

Conclusion

Advanced: contract testing with YoBox webhooks

Advanced: response time SLAs

Migration: from manual to monitored

Reporting

A deeper Postman workflow

Postman + Newman in CI/CD

Comparison: Postman vs. alternatives

Troubleshooting

FAQ

After months of building, testing, and refining, I'm excited to launch **YoBox** on Product Hunt!

ProductHunt #BuildInPublic #IndieHackers #WebDevelopment #DeveloperTools #Programming #Coding #OpenSource #SaaS #Webhooks #Docker #JSON #Regex #Productivity #DevCommunity #LaunchDay #Startups #Tech

Stripe and PayPal Webhook Testing: A Practical Guide

The Three Layers of Webhook Testing

Layer 1: Inspect the Payloads

Layer 2: Unit Test the Handler

Layer 3: End-to-End in Test Mode

Signature Verification: Stripe

Signature Verification: PayPal

Common Stripe Webhook Bugs to Test For

Common PayPal Webhook Bugs

What to Test Manually

End-to-End with Email

FAQ

Bottom Line

YoBox Team

The Only docker-compose.yml Pattern You Need (2026 Edition)

The five jobs a good compose file does

The pattern

Why each section matters

Local dev workflow

CI workflow

Comparison: common patterns

Pairs with

Common pitfalls

FAQ

Conclusion

Advanced: \develop.watch\ for hot reload

After months of building, testing, and refining, I'm excited to launch YoBox on Product Hunt!