DEV Community: yobox

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

Secure Test Credentials with the YoBox Password Generator

yobox — Tue, 21 Jul 2026 16:54:18 +0000

Test credentials are the most under-thought attack surface in modern engineering. Every team has a password: "Password123!" somewhere in a seed file or a Cypress fixture. Every team's CI logs probably contain that string. And every team is one accidentally-public S3 bucket away from an embarrassing incident report.

The YoBox Password Generator is built for exactly this problem: cryptographically strong, configurable, and easy to wire into any test suite. This article shows the patterns we recommend for credentials in Cypress, Playwright, Postman, and seed scripts.

Why "Password123!" is worse than you think

It's not just weak — it's fingerprinted. Public credential dumps include it. Bot scanners try it first. Compliance auditors flag it on sight. Even if your test environment is firewalled, the habit leaks: developers paste the same string into the dev environment, then staging, then "just this once" into production.

A unique password per fixture costs nothing and removes the entire class of incident.

The pattern

Generate a strong password at runtime, never check it in.

// helpers/credentials.ts
export const newPassword = () => {
const charset = "ABCDEFGHJKMNPQRSTUVWXYZabcdefghjkmnpqrstuvwxyz23456789!@#$%^&*";
const buf = crypto.getRandomValues(new Uint8Array(20));
return Array.from(buf, (b) => charset[b % charset.length]).join("");
};
In a browser/test environment, crypto.getRandomValues is the right primitive. Don't reach for Math.random — it's not cryptographically secure and any auditor will flag it. See Generating Cryptographically Secure Passwords in the Browser for the deep dive.

Cypress

Cypress.Commands.add("newCredentials", () =>
cy.task("newInbox").then((inbox) => ({
email: inbox.address,
inboxId: inbox.id,
password: Test!${Date.now()}-${Math.random().toString(36).slice(2, 10)},
}))
);
For tests that just need a credential and don't care about replay, that's enough. For tests that will be audited (SOC 2 evidence, pen-test runs), generate via crypto instead.

Playwright

import { test as base } from "@playwright/test";

export const test = base.extend<{ credentials: { email: string; password: string } }>({
credentials: async ({ inbox }, use) => {
const password = generateStrongPassword();
use({ email: inbox.address, password });
},
});

Postman / Newman

In a pre-request script:

const charset = "ABCDEFGHJKMNPQRSTUVWXYZabcdefghjkmnpqrstuvwxyz23456789!@#$%^&*";
const arr = new Uint8Array(20);
crypto.getRandomValues(arr);
const password = Array.from(arr, (b) => charset[b % charset.length]).join("");
pm.collectionVariables.set("password", password);

Seed scripts

The most common leak vector. Generate seed passwords at seed time, print the bcrypt hash to the DB, and emit the plaintext to a one-time-use file outside the repo.

import bcrypt from "bcryptjs";
import { writeFileSync, mkdirSync } from "fs";

mkdirSync(".secrets", { recursive: true });
const users = ["alice", "bob", "carol"].map((u) => {
const password = generateStrongPassword();
return { user: u, password, hash: bcrypt.hashSync(password, 12) };
});

writeFileSync(".secrets/dev-passwords.txt", users.map(u => ${u.user}\t${u.password}).join("\n"));

Add .secrets to .gitignore. Print the file path; never echo passwords to stdout in CI.

Configuring strength

The Password Generator UI exposes the same knobs you should expose in your helpers:

Knob Test default Production default
Length 20 24+
Symbols Yes Yes
Ambiguous chars Excluded Excluded
Numbers Yes Yes
Uppercase Yes Yes
Excluding ambiguous characters (0/O, 1/l/I) prevents the worst class of "I typed it wrong from the screenshot" bugs.

Pairs with

YoBox Temp Mail for fresh test emails.
Cypress + YoBox for end-to-end signup flows.
Regex Patterns Every QA Engineer Should Memorize for validating password complexity assertions.

Common pitfalls

Math.random() in security-adjacent code — never. Always crypto.getRandomValues.
Committing seed plaintext — keep it in .gitignored files.
Same password across environments — generate per environment, per run.
Echoing to CI logs — mask in GHA with ::add-mask::.

FAQ

Free tool
Generate Secure Password
Cryptographically strong, fully client-side.

Open
How long should test passwords be?
20 characters with mixed casing, numbers, and symbols. Long enough that brute-forcing is moot, short enough to type in a debugger.

Should I rotate test credentials?
Yes — per CI run, per local dev session. The whole point is throwaway.

What about service account credentials?
Different problem — use your secret manager (GitHub Actions secrets, AWS Secrets Manager). The password generator is for human test accounts.

Is the generator deterministic?
No, and it shouldn't be. Determinism would defeat the purpose.

Conclusion

Strong, unique, throwaway credentials cost nothing and eliminate the entire category of "leaked test password" incidents. The YoBox Password Generator gives you the UI; the patterns above wire it into Cypress, Playwright, Postman, and your seed scripts so your test data is as serious as your production data.

See also: Generating Cryptographically Secure Passwords in the Browser, Cypress + YoBox, Realistic Mock Data.

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

10 Regex Patterns Every QA Engineer Should Memorize

yobox — Sun, 19 Jul 2026 20:18:00 +0000

Regex is the single highest-leverage skill a QA engineer can sharpen in a weekend. The same ten patterns show up in every test suite: extract an OTP from an email, assert a UUID in a response, validate a URL, match a JWT, parse a currency string. Memorize them once and you stop pasting from Stack Overflow forever.

This guide gives you ten patterns that earn their keep in real Cypress, Playwright, and Postman suites — plus the Regex Assistant workflow we use to build new ones quickly.

How to read these patterns

Every example uses standard JavaScript / PCRE syntax. They're written to be strict enough to fail on garbage and loose enough to survive minor formatting drift. Where a stricter version exists, it's called out.

1. Six-digit OTP

\b\d{6}\b
The single most-used pattern in any test suite that touches signup. The word boundaries (\b) keep it from matching the 2026 in a year or the 123456 inside a longer transaction ID. Pair it with YoBox Temp Mail to read the OTP straight out of the email body. See the Cypress + YoBox guide for the full pattern.

2. Email address (pragmatic)

[A-Z0-9._%+-]+@[A-Z0-9.-]+.[A-Z]{2,}
Add the i flag. Don't try to implement RFC 5322 — nobody actually wants it. This pattern catches every realistic address and a few weird ones, which is exactly the trade-off you want in a QA assertion.

3. UUID v4

[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}
The 4 in position 13 and the [89ab] in position 17 are what make it a v4 assertion, not just "32 hex chars with dashes." Useful when you want to assert a freshly minted ID and not a recycled one from a fixture.

4. JWT structure

^[A-Za-z0-9_-]+.[A-Za-z0-9_-]+.[A-Za-z0-9_-]*$
Three base64url segments separated by dots. The signature segment can be empty for unsigned tokens — keep the * if you test those.

5. ISO 8601 timestamp

^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(.\d{1,6})?(Z|[+-]\d{2}:\d{2})$
Handles UTC and offset zones. Use this for API responses where the timestamp shape matters more than the value.

6. URL (loose but useful)

https?:\/\/[^\s)]+
Specifically tuned for extracting magic links from email bodies. The [^\s)]+ stops at whitespace or a closing paren so it survives markdown links.

7. Currency string

^[\$€£]?\d{1,3}(,\d{3})*(.\d{2})?$
Matches $1,299.00, €42, 1234.56. Tighten the optional decimal to .\d{2} only when your backend always returns two-decimal money.

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

Regex Without Tears: A 2026 Field Guide

yobox — Fri, 17 Jul 2026 12:55:14 +0000

Regex has a bad reputation it doesn't fully deserve. Yes, the syntax is dense. Yes, the wrong pattern can match the entire internet by accident. But once you internalize a small set of building blocks, regex becomes the highest-leverage skill in your toolkit — extraction, validation, refactoring, log parsing — all powered by the same five concepts.

This guide is the friendly version. No "elegant" lookaround puzzles. Just the patterns that show up in real code, explained without smugness.

The five concepts

Literals — cat matches cat.
Character classes — [abc] matches any one of a, b, c. \d is shorthand for [0-9]. \w is [A-Za-z0-9_]. \s is whitespace.
Quantifiers — * (zero or more), + (one or more), ? (zero or one), {3,5} (between 3 and 5).
Anchors — ^ start of string, $ end, \b word boundary.
Groups — (...) captures, (?:...) doesn't.
That's 90% of every regex you'll ever write.

The mental model that makes regex click

Regex engines are greedy by default — they try to match as much as possible. The ? after a quantifier makes it lazy. So . will eat everything up to the last x, while .? will stop at the first x. This single distinction explains 80% of the "why isn't this working" frustration.

Real patterns, explained

Extracting an OTP from an email
\b\d{6}\b
\b is a word boundary — the seam between a word character and a non-word character. Without it, \d{6} would match the first 6 digits of any longer number. See the Regex Patterns cheat sheet for variations.

Pulling a URL out of plain text
https?:\/\/[^\s)]+
https? means "http or https". [^\s)]+ is "anything that's not whitespace or a closing paren" — important for surviving markdown links like click.

Validating an email (pragmatically)
^[A-Z0-9._%+-]+@[A-Z0-9.-]+.[A-Z]{2,}$
With the i flag. Don't try to be RFC-perfect; you'll match nothing real users actually type.

Splitting CSV with quoted fields
Free tool
Try Regex Assistant
Live pattern testing with highlighted matches.

Open
This one's a trap. Don't use regex for real CSV — use a CSV library. Regex CSV parsers fall over on embedded quotes within a week.

Replacement: the second half of regex

String.prototype.replace with a regex is where most real wins happen.

"2026-06-09".replace(/(\d{4})-(\d{2})-(\d{2})/, "$3/$2/$1");
// → "09/06/2026"
Capture groups become $1, $2, etc. in the replacement string. Named groups are nicer:

"2026-06-09".replace(/(?\d{4})-(?\d{2})-(?\d{2})/, "$/$/$");

Lookaheads and lookbehinds

These exist. They're powerful. Use them sparingly.

(?<=\$)\d+.\d{2}
That matches a dollar amount without including the $ in the match. Useful occasionally. Confusing always. If you reach for a lookaround, leave a comment explaining what it does — your future self will thank you.

Flags

Flag Meaning
g Global — find all, not just first
i Case-insensitive
m ^/$ match per-line
s . matches newlines
u Unicode-aware
u matters more than it used to. Without it, \d doesn't match Arabic-Indic digits, \w doesn't match accented letters, and your i18n is silently broken.

Performance: when regex bites

Catastrophic backtracking is real. (a+)+ against "aaaaaaaaaaaa!" will hang. Avoid nested quantifiers; prefer possessive forms or atomic groups when your engine supports them. JavaScript engines have largely mitigated this with linear-time matching for many cases, but it's still worth knowing.

Tooling

The YoBox Regex Assistant is the fastest way to iterate on a pattern — paste a sample, type a regex, see what matches in real time. Three tips:

Start with the simplest pattern that matches your positive samples.
Add negative samples to prove the pattern doesn't over-match.
Only then add anchors and tighten character classes.

When NOT to use regex

Parsing HTML. Use a DOM parser.
Parsing JSON. Use JSON.parse.
Real CSV. Use a CSV library.
Anything with nested structure. Regex can't count.

A debugging checklist

When a regex doesn't match what you expect:

Is greedy matching eating too much? Try *? / +?.
Did you forget the i flag?
Are anchors in the right place? ^...$ is for whole-string match, not extraction.
Did you double-escape in a string literal? "\d" vs /\d/.
Are you matching against a multi-line string without the m flag?

Pairs with

10 Regex Patterns Every QA Engineer Should Memorize — the cheat-sheet companion.
Cypress + YoBox and Playwright + YoBox — where these patterns get used.

FAQ

Should I learn PCRE or JavaScript regex?
They overlap ~95%. Learn JS first; PCRE features (recursive patterns) are rarely needed.

Are regex visualizers worth it?
Yes, for learning. After a year, you'll read patterns faster than the visualizer renders them.

What about regex AI assistants?
Use them to draft, never to ship without testing. Run your patterns against the Regex Assistant before committing.

Is regex obsolete now that we have parsers and AI?
No. For unstructured text — logs, emails, free-text fields — regex is still the right tool.

Conclusion

Regex isn't hard. It's just dense. Internalize the five building blocks, write the pattern in the Regex Assistant, test it against negatives, and you'll spend the rest of your career reaching for regex when other developers reach for 40-line string-manipulation functions.

See also: 10 Regex Patterns Every QA Engineer Should Memorize, Cypress + YoBox.

Worked example: extracting dates from log lines

\\
2026-06-09 14:21:00 INFO User signed up
\\

Pattern: ^(\d{4}-\d{2}-\d{2}) (\d{2}:\d{2}:\d{2}). Capture group 1 is the date, group 2 the time. Readable, fast, no lookarounds.

Worked example: refactoring imports

A safer alternative to a sed one-liner:

\\bash
rg -l "from ['\"]lodash['\"]" | xargs sed -i 's/from .lodash./from "lodash-es"/g'
\\

The regex is loose on the quote style and tight on the module name — exactly the trade-off you want for codemods.

When to reach for a parser instead

If your input has nested structure — JSON, HTML, source code — reach for the appropriate parser. Regex can match arbitrarily deep balanced parentheses only with engine-specific recursion features that vary across runtimes.

Building intuition

The fastest way to build regex intuition is to write the pattern in plain English first, then translate piece by piece. "Three digits, then a dash, then four digits" becomes \\d{3}-\d{4}. Read patterns the same way and they stop feeling cryptic within a week.

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 GitHub Accounts: What Works and What Doesn't

yobox — Tue, 14 Jul 2026 20:06:51 +0000

Temporary Email for GitHub Accounts: What Works and What Doesn't
GitHub used to be one of the easier platforms to sign up to with disposable email. As of 2026, that's no longer true. The signup form now checks email domains against a blocklist, requires email verification before you can push code, and adds friction (captchas, secondary verification) when it detects suspicious patterns.

If you're trying to create a GitHub account without using your personal email — for testing, for a bot, for an alt — this is what actually works in 2026.

Why You Might Want a Disposable GitHub Account

Legitimate reasons:

Testing OAuth integrations. You're building "Sign in with GitHub" and need a clean account.
CI testing. Automated tests need to push to a sandbox repo.
Open-source contributions under a pseudonym. You want to separate work from personal.
Bot accounts. A GitHub Actions workflow needs its own identity.
Learning / experimentation. You want to try something risky without polluting your main account.
GitHub allows multiple accounts as long as they're not for spam or abuse. The email is the gating step.

What Doesn't Work

Tested as of mid-2026:

temp-mail.org and clones. Blocked.
mail.tm public domains. Mostly blocked.
10minutemail. Blocked.
Guerrilla Mail. Blocked.
Mailinator. Blocked.
GitHub's check happens before they send the verification email, so you get a generic "please use a valid email address" error.

What Works

Three approaches in increasing order of reliability:

Rotating-domain temp mail (sometimes)
A few services rotate through fresher domains. The YoBox Temp Mail tool uses a rotating upstream pool and sometimes slips through GitHub's filters — but expect failure. If it fails, the form rejects the email immediately, and you can try a new address.
Email aliases (reliable)
SimpleLogin, AnonAddy, Apple Hide My Email, and ProtonPass generate forwarding addresses that look like permanent personal email. GitHub generally accepts these. The verification email arrives in your real inbox; you click the link; you're verified.

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

Open
This is the path that actually works in 2026.

Your own domain (most reliable) If you own a domain and configure a catch-all forwarder, you can generate as many github-test@yourdomain addresses as you want. GitHub will never blocklist your private domain. Highest setup cost, highest reliability.

A Clean Setup for Developers

The setup we recommend:

Buy a domain (yourname.dev or similar) — $10/year.
Configure email forwarding via Cloudflare Email Routing (free) or ImprovMX (free tier).
Generate per-account addresses like github-personal@yourname.dev, github-bot@yourname.dev.
All emails forward to your real inbox.
Each address can be killed independently if leaked.
This gives you unlimited GitHub accounts (within GitHub's ToS) with zero risk of blocklisting and full recoverability.

Comparison

Approach Works on GitHub? Long-term usable? Setup effort
Personal Gmail Yes Yes None
Alias (SimpleLogin etc.) Usually Yes Low
Custom domain catch-all Yes Yes Medium
YoBox / rotating disposable Sometimes No (inbox dies) None
Fixed-domain disposable No No None

The Specific Friction Points

Even if you get past the email step, GitHub adds friction:

SMS verification for accounts created from unusual IPs or with disposable-looking emails. Disposable phone numbers face the same blocklist problem.
2FA enforcement. Required for many operations. If your email is disposable, you'll lose 2FA recovery.
Push restrictions. Unverified accounts can't push to public repos.
Marketplace restrictions. Buying or installing certain apps requires a verified, paid-plan-eligible account.
Each of these is harder to satisfy on a throwaway account.

When Disposable Is Actually Fine

There are use cases where disposable email is the right answer for GitHub:

Signing up to read a private repo someone shared with you. Read access doesn't need 2FA.
One-off OAuth testing. Sign in with GitHub for 5 minutes, then walk away.
Spinning up a GitHub Codespace for a quick experiment.
For these, YoBox Temp Mail is fine — if it gets past the signup filter, you're done.

When Disposable Will Hurt You

Pushing code to a long-lived repo. If you lose the inbox, you lose recovery.
CI / Actions workflows that depend on the account. Long-term workflows need a long-term account.
Anything tied to a paid plan. Billing emails matter.
Bot accounts that handle real work. Use a real email or a dedicated alias.

Developer Note: Testing GitHub OAuth and Webhooks

If you're building an integration that uses GitHub (OAuth login, webhooks for repo events, App installation), you don't necessarily need a disposable GitHub account — you need a test GitHub account, which is allowed under ToS as long as it's a real account.

For inspecting what GitHub actually sends in webhooks (push, pull_request, issues), point the webhook at the YoBox Webhook Tester and trigger events in your test repo. You'll see the exact JSON GitHub delivers, including the X-Hub-Signature-256 header for signature verification.

FAQ

Can I sign up to GitHub with mail.tm?
Mostly no. Public mail.tm domains are blocklisted.

What's the best disposable email for GitHub?
None reliably. Use an alias (SimpleLogin, Apple Hide My Email) instead.

Will GitHub ban my account if I use a temp email?
Not automatically. But disposable signups face extra verification, and if you can't pass it, you'll lose access.

Can I create multiple GitHub accounts?
Yes, as long as they're not for spam, abuse, or evading suspensions. GitHub's policy explicitly allows multi-account users.

How do I keep alt GitHub accounts long-term?
Use a custom domain + catch-all email. The accounts will outlive every disposable service.

Bottom Line

In 2026, the reliable path to a non-personal GitHub account is an email alias or a custom domain — not disposable email. Save YoBox Temp Mail for one-off use cases (quick OAuth tests, brief signups) and use real-looking email for any account you want to keep. Pair with the Webhook Tester when you need to inspect what GitHub sends to your integrations.

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.

Stop Using Fake Data in Your API Tests

yobox — Sat, 11 Jul 2026 21:27:54 +0000

Stop Using Fake Data in Your API Tests

If you're still testing APIs with fake payloads copied from documentation, you're probably missing the bugs that actually happen in production.

One of the biggest mistakes developers make is building tests around "perfect" data instead of real-world traffic.

Here's a workflow that has saved me hours when working with webhooks, email verification, and end-to-end testing.

Step 1 — Capture Real Data

Instead of inventing JSON payloads, capture a real request.

A webhook inspector lets you see exactly what Stripe, GitHub, Clerk, or another provider sends, including:

Headers
Request body
Timing
Delivery information

Once you have that payload, save it as a fixture for future tests.

Step 2 — Test Real Email Flows

Many signup systems rely on OTP emails or verification links.

Using your personal inbox quickly becomes messy.

A disposable inbox lets you create clean test accounts every time without polluting your real email.

Step 3 — Replay the Workflow

Once you have:

Real webhook payloads
Real email messages
Real API responses

You can replay the entire flow inside Cypress or Playwright instead of relying on mocked data.

Your tests become much closer to production behavior.

My Current Stack

Playwright
Cypress
Postman
Docker
Disposable email
Webhook inspector

I've been collecting practical examples for these workflows here:

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

The examples are completely public.

If you're building internal tools, SaaS products, or API integrations, I'd love to know:

What's the most annoying part of your current testing workflow?

How to Debug Webhooks Locally (Without Going Insane)

yobox — Wed, 08 Jul 2026 19:22:16 +0000

Debugging a webhook is supposed to be simple. The provider sends a POST. Your code receives it. You log the payload, you fix the bug, you move on.

In practice it's a parade of small problems: the provider can't reach localhost, you don't know what payload arrives, the signature verification fails for opaque reasons, the event you need to trigger only happens once a week, and you spend an hour chasing a body-parsing bug that turns out to be a Content-Type mismatch.

This is the playbook for debugging webhooks locally without that pain.

The Five Problems

Every local webhook debugging session bumps into the same five problems:

The provider can't reach localhost. You need a public URL.
You don't know what the provider actually sends. Docs lie, fields change.
Signature verification fails. Often a body-parsing issue.
You can't trigger the event on demand. "Charge succeeded" needs a real charge.
You can't replay an event. First-time debugging is wasted.
Each has a clean fix.

Problem 1: The Public URL

Two clean solutions, depending on what you need:

Option A: ngrok / localtunnel
Spin up a tunnel from your laptop to a public URL. Providers POST to the public URL; ngrok forwards to localhost.

ngrok http 3000

→ https://abc-123.ngrok-free.app forwards to localhost:3000

Use this when you're iterating on your real handler.

Option B: Capture-then-replay
Instead of running your handler live, capture the payload with a tool like the YoBox Webhook Tester, then replay it against your local handler with curl or a test script. This decouples seeing the payload from running the handler.

After capturing in YoBox, copy the body to /tmp/payload.json

curl -X POST http://localhost:3000/webhooks/stripe \
-H 'Content-Type: application/json' \
-H 'Stripe-Signature: t=...,v1=...' \
--data-binary @/tmp/payload.json
Use this when you want to iterate fast without re-triggering provider events.

Problem 2: What Does the Provider Actually Send?

Docs are out of date. Schemas change. The only ground truth is what the provider actually sends. Capture it.

Generate a URL in the YoBox Webhook Tester, paste it into the provider's webhook config (Stripe dashboard, GitHub repo settings, etc.), trigger the event, and read the raw request. You'll see:

Full headers (including signature)
Query string
Body (JSON, form-encoded, whatever)
Timing
This is how you discover that "the docs say customer.id but the actual payload puts it at data.object.customer." Don't code against docs; code against captures.

Problem 3: Signature Verification Failing

Free tool
Open Webhook Tester
Capture & inspect HTTP requests in real time.

Open
The single most common local webhook bug is "signature doesn't match." 90% of the time, the cause is the body being parsed before verification.

Most signature schemes (Stripe, GitHub, Shopify, Slack) hash the raw request body. If you have Express's express.json() middleware globally enabled, it parses the body into an object first and the original byte sequence is lost. The hash you compute won't match.

Fix: Use raw body parsing for webhook routes specifically.

// Express
app.use('/webhooks', express.raw({ type: 'application/json' }));
app.post('/webhooks/stripe', (req, res) => {
const signature = req.headers['stripe-signature'];
const event = stripe.webhooks.constructEvent(req.body, signature, secret);
// ...
});
// Fastify
fastify.addContentTypeParser('application/json', { parseAs: 'buffer' }, (req, body, done) => {
done(null, body);
});
// Next.js App Router
export async function POST(req: Request) {
const rawBody = await req.text(); // Don't JSON.parse first
const signature = req.headers.get('stripe-signature')!;
const event = stripe.webhooks.constructEvent(rawBody, signature, secret);
}
Other signature pitfalls:

Use timing-safe comparison. crypto.timingSafeEqual, not ===.
Reject old timestamps. Most schemes include a timestamp; reject if older than 5 minutes to prevent replay.
Don't trim whitespace. The body is exactly what was sent. Don't normalize it.

Problem 4: Can't Trigger the Event on Demand

Webhook events for things like charge.disputed or subscription.canceled are hard to trigger in real life. Solutions:

Use the provider's CLI / test mode
Stripe: stripe trigger payment_intent.succeeded and many more
GitHub: the "Redeliver" button on past deliveries
Shopify: test webhooks from the admin
Twilio: simulate inbound messages from the console
Replay captured payloads
Capture a real production event (in a test environment) with YoBox Webhook Tester, save the body, replay it against your local handler. You can now iterate on the handler against a real payload without re-triggering it.

Write a payload generator
For events without good triggering, write a small script that constructs the payload your handler expects and POSTs it. Useful in unit tests.

Problem 5: Can't Replay Events

The provider sends the event once. You catch a bug. Now what?

The clean pattern is: capture all events to a log, replay from the log.

In production, every webhook handler should write the raw payload to a queue or log before processing. In development, the YoBox Webhook Tester does this for you — every captured event is browsable and copy-pasteable.

Once you have the payload, replay it as many times as you need:

for i in {1..10}; do
curl -X POST http://localhost:3000/webhooks/stripe \
-H "Content-Type: application/json" \
--data-binary @/tmp/payload.json
done
Use this to test idempotency: the same payload should produce the same database state, no matter how many times it arrives.

A Full Local Workflow

The workflow we use:

Capture first. Generate a YoBox Webhook Tester URL, paste into provider, trigger event, read payload.
Save the payload to /tmp. This is your fixture.
Write a curl one-liner that POSTs the fixture to your local handler.
Iterate on the handler. Each change, replay the fixture. No re-triggering needed.
Once handler works on fixture, run end-to-end against ngrok. Confirm signature verification works with a real signature.
Run a load test with the curl loop. Confirm idempotency.
Deploy to staging. Configure staging webhook URL. Confirm in real env.
This decouples getting the payload from iterating on the handler, which is the single biggest productivity win.

Local Webhook Debugging Checklist

When something's wrong:

[ ] Is the public URL reachable? (curl https://your-tunnel-url from another machine)
[ ] Did the provider actually send? (Check provider's webhook log)
[ ] What did it send? (Capture in YoBox and inspect)
[ ] Does signature verification pass? (Log raw body length and computed hash)
[ ] Is the body parsed before verification? (Check middleware order)
[ ] Is the handler returning 2xx in under 10s? (Check provider's retry log)
[ ] Is the handler idempotent? (Run the curl loop)

FAQ

Can I debug webhooks without ngrok?
Yes — use YoBox Webhook Tester for capture, then replay payloads against localhost with curl. You only need ngrok if you want the provider to call your real handler live.

Why does Stripe's signature fail on Vercel?
Almost always because Next.js / Express body parsing converts the body before verification. Use raw body in the webhook route.

How long should I keep captured webhooks for debugging?
Save what you need to /tmp or commit fixtures to your repo. Don't rely on capture services for long-term storage.

Can I run webhook debugging in CI?
Yes — use the YoBox Webhook Tester API to capture and assert in tests. See "Webhook Testing Complete Guide".

Is it safe to use a public capture tool with production data?
Avoid it. Production webhooks contain real PII / financial data. Use staging environments or self-hosted capture for production debugging.

Bottom Line

Local webhook debugging is fast when you capture first, replay against fixtures, and verify signatures against the raw body. YoBox Webhook Tester handles the capture; curl handles the replay; your handler handles the work. Don't try to debug live every time — capture once, iterate fast.

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.

How to Pick a Monorepo Tool in 2026

yobox — Mon, 29 Jun 2026 15:26:03 +0000

The landscape: Turborepo (caching focus), Nx (plugin ecosystem), pnpm workspaces (minimal, native), Bun workspaces (fast, batteries-included).

Quick decision tree

2-3 packages, no CI bottleneck → pnpm workspaces.
Heavy CI, many TS packages → Turborepo.
Polyglot, multiple frameworks → Nx.
Greenfield, Bun-only → Bun workspaces.
Don't over-engineer. Most teams pick Turbo and never touch the cache settings.

Why this decision matters more in 2026

A monorepo tool is the foundation under every other build decision you make. It dictates how fast CI runs, how easily new engineers onboard, how cleanly you can extract a package, and how much your release process hurts. Picking wrong is not catastrophic — every tool here can be replaced — but the cost of switching grows linearly with package count and team size. Spend an afternoon on the decision now; you will save a week of migration later.

The good news: the four serious options in 2026 are all genuinely good. There is no "obvious wrong answer." The bad news: each tool is opinionated, and adopting one without understanding those opinions is how teams end up rewriting their CI six months later.

The right monorepo tool is the one whose defaults match your team's actual workflow — not the one with the prettiest dashboard.

The contenders

Turborepo
Caching-first. Turbo's core value is "never run the same task twice," and it delivers that with a remote cache that works out of the box on Vercel and self-hosts in ~20 lines of config. It stays out of the way for everything else, which is both its strength (low cognitive overhead) and its limit (you bring your own conventions).

Nx
Plugin-first. Nx ships generators, executors, dependency graphs, and affected-detection for ~30 frameworks. If your monorepo is polyglot (React + NestJS + React Native + Go), Nx gives you a single command surface across all of them. The trade-off is that Nx wants to own your workflow — embrace it and it is delightful, fight it and it is painful.

pnpm workspaces
Minimal. No task runner, no caching, no graph — just pnpm -r run build and a sane node_modules layout. For 2–10 packages, this is often all you need. Pair it with pnpm --filter ... for selective runs and a homegrown caching layer if CI gets slow.

Bun workspaces
Fast. Bun's workspace support is solid in 2026, and bun install is dramatically faster than alternatives. The task runner is rudimentary compared to Turbo/Nx, but for greenfield Bun-only projects the integrated story is hard to beat.

Comparison at a glance

Concern Turborepo Nx pnpm workspaces Bun workspaces
Setup time 10 min 30 min 2 min 2 min
Remote caching First-class First-class DIY DIY
Affected detection Yes Yes (best-in-class) DIY DIY
Generators / scaffolds None Many None None
Polyglot support Language-agnostic Best Node-only Node-only
Learning curve Low High None None
Lock-in risk Low Medium-high None Low
Best at TS monorepos Enterprise polyglot Small teams Greenfield speed
Free tool
Try YoBox Temp Mail
Disposable inbox — no signup, instant OTP.

Open
Lock-in risk is the underrated axis. Turbo and pnpm are easy to leave. Nx generators write code that assumes Nx — leaving means rewriting that code.

A decision tree that actually works

Start here
Do you have 2–4 packages and CI under 5 minutes? Use pnpm workspaces. Anything else is over-engineering.
Is the project greenfield, Bun-first, and unlikely to need polyglot support? Use Bun workspaces.
Do you have many TypeScript packages and CI pain? Use Turborepo.
Are you polyglot (multiple frameworks, possibly multiple languages) and willing to adopt opinions? Use Nx.
Tiebreakers
If your team already uses Vercel, Turborepo's remote cache is free and zero-config.
If you ship a design system across many apps, Nx generators reduce the per-app boilerplate dramatically — relevant if you also migrated to Tailwind v4.
If your CI runs Docker builds, pair any choice with the Docker Builder Guide to keep image caches warm.

Real use cases

A two-person startup shipping a React app + a marketing site
pnpm workspaces. One packages/ui shared library, two consumers, no task runner. Adding Turbo here is a solution looking for a problem.

A 15-engineer company with a React app, a NestJS API, and a shared TS contracts package
Turborepo. The caching pays for itself within a week, and the conventions stay invisible. CI drops from 12 minutes to 3.

A 60-engineer enterprise with React, React Native, NestJS, Go services, and a design system
Nx. The generators, the dependency graph, and the affected-detection across languages are worth the learning curve. The investment in custom Nx executors becomes a moat.

A Bun-only side project with three packages
Bun workspaces. bun install in 200 ms, bun run --filter '*' build covers the basics, and you ship faster than you would have spent setting up Turbo.

CI patterns that pay off regardless of tool

Cache the package manager store
pnpm store, Bun's global cache, and Nx's node_modules cache all benefit from explicit CI caching keyed on the lockfile hash. This is the single biggest CI win across every tool.

Run affected, not all
Whether you call it turbo run build --filter=...[HEAD^], nx affected -t build, or a custom git diff script, only building changed packages drops CI time by 60–90% on a healthy monorepo.

Pin the tool version
packageManager in package.json for pnpm/Bun, and a fixed Turbo/Nx version in devDependencies. Floating versions in a monorepo cause the worst kind of "works on my machine" bug.

Keep one CI entry point
ci/run.sh that delegates to the tool. When you eventually switch tools, you change one file.

Key takeaways

pnpm workspaces is the right default for small repos.
Turborepo wins for TS-heavy monorepos with CI pain.
Nx wins for polyglot enterprise repos that benefit from generators.
Bun workspaces wins for greenfield, Bun-only projects.
Pin tool versions, cache the store, and always run affected — these matter more than the tool choice.

FAQ

Can I mix pnpm workspaces and Turborepo? Yes — that is the most common production setup. pnpm handles installation, Turbo handles task orchestration and caching.
Is Nx overkill for a 10-package repo? For a homogeneous TS repo, yes. For a polyglot repo, no. The line is "do you have more than two frameworks?"
Does Bun replace Turbo? Not yet. Bun is a fast package manager and runtime; Turbo is a task orchestrator with remote caching. They can coexist (packageManager: bun with Turbo on top).
How do I migrate from Lerna? Lerna is effectively legacy in 2026. Most teams move to pnpm workspaces + Turbo. The migration is mechanical: delete lerna.json, add pnpm-workspace.yaml, replace lerna run with turbo run.
What about Rush / Bazel? Rush is solid but losing momentum. Bazel is correct for massive (1000+ package) polyglot monorepos and overkill for everything else.

Conclusion

The 2026 monorepo landscape is healthy enough that you do not need to agonize over the choice. Pick the simplest tool that solves your current pain — pnpm workspaces until CI hurts, Turborepo when it does, Nx when polyglot complexity dominates, Bun when you are starting from scratch and Bun-only. Wrap whatever you pick in a single CI entry point so the next migration is a one-file change, and spend the rest of your energy on the work the monorepo actually contains.

Anti-patterns to avoid

Adopting a task runner before you need one A two-package repo with a 30-second build does not need Turbo or Nx. Adding either means onboarding cost, configuration files, and a learning curve that pays back only when CI hurts. Wait for the pain; then solve it.
Pinning everyone to a custom Nx executor Nx executors are powerful but viral — every package that uses one is now bound to the executor's API. Use built-in executors wherever possible, and write custom ones only when the productivity win is undeniable.
Caching without invalidation discipline A remote cache that returns stale outputs is worse than no cache at all. Be explicit about inputs (env vars, file globs, tool versions) for every cached task. The first time CI ships a cached "green" build that should have failed, the team loses trust in the cache forever.
Letting workspace dependencies drift workspace:* is convenient but loose. For published packages, pin to exact versions and bump them with a changesets-style workflow. The discipline pays off the first time you publish a breaking change.
Treating the monorepo as a deployment unit Packages share a repo; they should not share a release cadence. Independent versioning, independent CI pipelines, and independent deploys are the point of the monorepo — collapsing them back into a monolith undoes the value. Combine this discipline with the CI patterns from the Docker Builder Guide and the testing flows in the Cypress and Playwright guides for a release pipeline that scales with the repo.

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.

Realistic Mock Data for Cypress, Playwright & Postman

yobox — Tue, 23 Jun 2026 13:26:06 +0000

The cheapest test failure to debug is the one that says exactly what's wrong. The most expensive one is the test that passes against "test@test.com" and "John Doe" and then explodes the moment a real user with an apostrophe in their name signs up. Realistic mock data is the difference.

This guide covers a complete mock-data toolkit for Cypress, Playwright, and Postman — emails from YoBox, passwords from the Password Generator, filler text from Lorem Ipsum, and a few patterns for the long tail of edge cases.

Why "test@test.com" is a problem

"test@test.com" has been registered as a real account on most major SaaS apps at least once a day for the last decade. Your CI is competing with everyone else's. Worse, your tests probably pass because the response matches expectations — even when the database update silently failed because a unique constraint fired.

The fix is one HTTP call:

const inbox = await fetch("https://yobox.dev/api/mail/new", { method: "POST" }).then(r => r.json());
Now every test gets an address no one else owns, ever.

The four categories of mock data
Category Source Edge cases to cover
Emails YoBox Temp Mail Plus addressing, long local part
Passwords Password Generator Unicode, length 64+
Names Faker / custom Apostrophes, CJK, RTL
Long text Lorem Ipsum Newlines, emoji, HTML entities
The first two are completely solved by YoBox. The other two need a faker library plus deliberate edge cases.

A reusable factory module

// tests/factories.ts
import { faker } from "@faker-js/faker";

const YOBOX = process.env.YOBOX ?? "https://yobox.dev/api";

export async function makeUser() {
const inbox = await fetch(${YOBOX}/mail/new, { method: "POST" }).then(r => r.json());
return {
email: inbox.address,
inboxId: inbox.id,
firstName: faker.person.firstName(),
lastName: faker.person.lastName(),
password: faker.internet.password({ length: 20, memorable: false, prefix: "T!" }),
};
}

export const edgeCaseUsers = [
{ firstName: "O'Brien", lastName: "Müller" },
{ firstName: "李", lastName: "明" },
{ firstName: "Ñoño", lastName: "García" },
{ firstName: "Anne-Marie", lastName: "de la Vega" },
];

That one file covers 95% of the variety you need.

Cypress

import { makeUser, edgeCaseUsers } from "../factories";

describe("Signup variety", () => {
it("happy path", () => {
cy.wrap(makeUser()).then((u) => {
cy.visit("/signup");
cy.get("[data-test=email]").type(u.email);
// ...
});
});

edgeCaseUsers.forEach((u) => {
it(handles "${u.firstName} ${u.lastName}", () => {
cy.wrap(makeUser()).then((base) => {
cy.visit("/signup");
cy.get("[data-test=first]").type(u.firstName);
cy.get("[data-test=last]").type(u.lastName);
cy.get("[data-test=email]").type(base.email);
});
});
});
});

Playwright

import { test, expect } from "./fixtures";
import { makeUser } from "./factories";

test("variety", async ({ page }) => {
const u = await makeUser();
await page.goto("/signup");
await page.getByLabel("Email").fill(u.email);
await page.getByLabel("First name").fill(u.firstName);
});

Postman

In a pre-request script:

Long-form text
For description fields, comment bodies, blog posts:

const longText = await fetch("/* lorem source */").then(r => r.text());
Or simply paste blocks from YoBox Lorem Ipsum into a fixtures file. Include at least one block with emoji, one with newlines, and one with HTML entities — they catch the most regressions.

Payload fixtures

Free tool
Open Cypress Guide
End-to-end recipes for Cypress + YoBox.

Open
Don't write JSON by hand:

export const invoicePayload = (overrides = {}) => ({
id: crypto.randomUUID(),
customer_email: "",
amount_cents: 4200,
currency: "USD",
created_at: new Date().toISOString(),
...overrides,
});
Override the fields a test actually cares about; leave the rest as realistic defaults.

Edge cases worth always testing

Email with +tag addressing.
Name with a single apostrophe.
Name with a hyphen.
256-character display name.
Empty middle name vs missing middle name ("" vs undefined).
Currency with thousands separator.
Timestamps in non-UTC zones.

Pairs with

YoBox Temp Mail for unique inboxes.
Password Generator for credentials.
Lorem Ipsum for body copy.
Regex Patterns cheat sheet for validation assertions.

Common pitfalls

Hard-coded "test@test.com" — every issue traceable to this string is your fault.
No CJK or RTL coverage — your i18n layer is untested.
Predictable timestamps — new Date(0) everywhere will hide timezone bugs.
Reusing the same fake user — defeats the purpose of fixtures.

FAQ

Should I commit fixtures to git?
Static fixtures yes; generated user data no.

Is Faker deterministic?
It can be, via faker.seed(123). Use seeded data for snapshot tests, random for everything else.

How big should a fixture file be?
Small. If it's over 200 lines, you're testing the fixture, not the app.

What about PII?
Never use real customer data, even anonymized. Faker + YoBox covers every legitimate need.

Conclusion

Realistic mock data is the cheapest quality investment your team can make. YoBox gives you the inboxes and the passwords; Faker plus a small edge-case list covers names and payloads; Lorem Ipsum covers prose. Wire it all into a single factories module and every test in Cypress, Playwright, and Postman gets variety for free.

See also: Stop Using Fake Data in Production Demos, Cypress + YoBox, Secure Test Credentials.

Locales and i18n

Faker supports locale-specific data. Set \faker.locale = "ja"\ for Japanese names and addresses, then run your suite in that locale to catch text-direction and character-width bugs.

Payment data

Use Stripe's published test card numbers (\4242 4242 4242 4242\ for success, \4000 0000 0000 0002\ for decline) — never generate fake card numbers, even for tests. Real card-number formats can trigger fraud rules in scanners.

Date and timezone variety

Generate timestamps across at least three timezones in every fixture set. The bugs around DST, leap seconds, and ISO formatting are not edge cases — they are weekly cases in any global app.

Migration from fixed fixtures
Replace \fixture("user.json")\ calls with factory calls one folder at a time. Each PR is small, reviewable, and instantly increases coverage of the messy edges that fixed fixtures never exercise.

A data generation strategy that survives contact with reality

Mock data should be realistic, deterministic, and disposable. Realistic so you catch shape bugs; deterministic so failures reproduce; disposable so a leak is a non-event.

The standard stack:

Faker for shapes (names, addresses, lorem ipsum).
A seeded RNG so two runs of the same test produce the same data.
YoBox primitives for things Faker can't produce — real inboxes, real webhook URLs, real cryptographic strings.

import { faker } from "@faker-js/faker";
faker.seed(42);

export function buildUser(runId: string) {
return {
name: faker.person.fullName(),
email: qa+${runId}@yobox.dev,
company: faker.company.name(),
bio: faker.lorem.sentences(2),
};
}

Cypress fixtures vs. factories

Fixtures (cypress/fixtures/user.json) are great for static reference data. The moment a value must differ per run — an email, a username, a timestamp — switch to a factory function called from your test.

// cypress/support/factories.ts
export const newUser = () => ({
email: qa+${Date.now()}@yobox.dev,
password: crypto.randomUUID(),
});

Playwright + storage state

Playwright's storageState lets you log in once and reuse the session across tests. Pair this with a factory that registers a fresh user during globalSetup so every CI run gets a clean account.

// playwright/global-setup.ts
import { chromium } from "@playwright/test";
export default async function () {
const browser = await chromium.launch();
const page = await browser.newPage();
// sign up using YoBox temp mail for the OTP
await page.goto("/signup");
// ...
await page.context().storageState({ path: "state.json" });
await browser.close();
}

Postman: dynamic variables done right

Postman ships dozens of {{$random...}} variables. The trap is that they regenerate on every reference, so chaining requests with the same value requires capturing once:

pm.collectionVariables.set("email", qa+${pm.variables.replaceIn("{{$timestamp}}")}@yobox.dev);

Realistic vs. random

Random data is not realistic data. asdf qwer will pass most validators and miss every visual bug. Faker's locale-aware generators (faker.location.streetAddress({ useFullAddress: true })) catch UI overflows that random strings will not.

Generator Realism Determinism Use when
Faker (seeded) High Yes Default for E2E suites
Random ASCII None Easy Property tests, fuzzing
Production-derived dumps Highest Yes Never (PII risk)
YoBox Temp Mail address Real Per-run Anything that sends real email

Troubleshooting

Tests pass with mock data, fail with real users.
Your mock data is too uniform. Inject edge cases: names with apostrophes, addresses without zip codes, emoji in bios.

Faker output changes between versions.
Pin Faker as an exact dependency in CI, or your snapshot tests will explode after a routine upgrade.

Postman variables behave unpredictably across requests.
Use pm.collectionVariables for per-run values and pm.variables only for true throwaways.

FAQ

Should I share fixtures across Cypress and Playwright?
If both suites cover the same flows, yes. Extract a fixtures/ package and consume from both. Otherwise you'll drift.

How do I avoid PII in test data?
Generate everything. Never copy from production. If you must mirror production shape, anonymize at the dump stage, not at the test stage.

What about contract tests?
Pact or Postman's schema tests cover contracts; mock data covers behavior. They're complementary, not competing.

Where does YoBox fit?
Temp Mail replaces hand-rolled inbox stubs. The Webhook Tester replaces requestbin-style listeners. The Password Generator replaces Password123!. Pull each in as you need it instead of building local equivalents.

Comparison: fixture files vs. factories vs. live faker

Approach Reproducibility Edge-case coverage Refactor cost Best for
Static JSON fixtures Perfect Low — only what you typed High — touch every file Snapshot tests, contract tests
Seeded factories Perfect (with a seed) High — randomized within rules Low — change the factory Most E2E and integration tests
Live faker (unseeded) None Maximum Low Exploratory and fuzz testing
Fixed fixtures lie to you. They pass on Monday because nothing changed since Friday, not because the code is correct. Factories with a seeded RNG give you reproducibility and breadth at the same time.

Real use cases

Cypress signup flows with Temp Mail
Combine a seeded factory with a fresh YoBox inbox per spec. The factory mints a realistic name, address, and locale; YoBox mints a real email address that actually receives the verification message. The Cypress + YoBox guide shows the full custom-command setup.

Playwright parallel-safe fixtures
When Playwright runs eight workers in parallel, every worker needs a unique user. A factory keyed off test.info().workerIndex guarantees uniqueness without coordination. See the Playwright + YoBox guide for the worker-scoped fixture pattern.

Postman collections shared across teams
A Postman collection that hardcodes { "email": "alice@example.com" } breaks the moment two engineers run it against the same environment. Replace the body with {{$randomEmail}} or, better, a pre-request script that calls into a factory function. The Postman + YoBox guide covers the YoBox-backed assertion side.

CI seed data for staging
The same factory that generates test data in Cypress can seed staging databases. One module, two callers — staging looks like production, and your QA team stops asking for "more realistic data."

Key takeaways

Treat test data as code: version it, review it, and refactor it.
Seed your RNG so failures are reproducible without sacrificing coverage.
Use real domains (example.com) or YoBox-issued inboxes for email fields — never test@test.com.
Generate one realistic value per attribute rather than copy/pasting the same string twelve times.
Ship a factory module on day one; retrofitting it after a hundred specs is painful.
The bugs your tests miss live in the data your tests never generate. Realistic mock data is the cheapest coverage you can buy.

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.

Secure Test Credentials with the YoBox Password Generator

yobox — Mon, 22 Jun 2026 16:44:34 +0000

Why "Password123!" is worse than you think

A unique password per fixture costs nothing and removes the entire class of incident.

The pattern

Generate a strong password at runtime, never check it in.

Cypress

Playwright

import { test as base } from "@playwright/test";

export const test = base.extend<{ credentials: { email: string; password: string } }>({
credentials: async ({ inbox }, use) => {
const password = generateStrongPassword();
use({ email: inbox.address, password });
},
});

Postman / Newman

In a pre-request script:

Seed scripts

The most common leak vector. Generate seed passwords at seed time, print the bcrypt hash to the DB, and emit the plaintext to a one-time-use file outside the repo.

import bcrypt from "bcryptjs";
import { writeFileSync, mkdirSync } from "fs";

mkdirSync(".secrets", { recursive: true });
const users = ["alice", "bob", "carol"].map((u) => {
const password = generateStrongPassword();
return { user: u, password, hash: bcrypt.hashSync(password, 12) };
});

writeFileSync(".secrets/dev-passwords.txt", users.map(u => ${u.user}\t${u.password}).join("\n"));

Add .secrets to .gitignore. Print the file path; never echo passwords to stdout in CI.

Configuring strength

The Password Generator UI exposes the same knobs you should expose in your helpers:

Pairs with

YoBox Temp Mail for fresh test emails.
Cypress + YoBox for end-to-end signup flows.
Regex Patterns Every QA Engineer Should Memorize for validating password complexity assertions.

Common pitfalls

FAQ

Free tool
Generate Secure Password
Cryptographically strong, fully client-side.

Open
How long should test passwords be?
20 characters with mixed casing, numbers, and symbols. Long enough that brute-forcing is moot, short enough to type in a debugger.

Should I rotate test credentials?
Yes — per CI run, per local dev session. The whole point is throwaway.

What about service account credentials?
Different problem — use your secret manager (GitHub Actions secrets, AWS Secrets Manager). The password generator is for human test accounts.

Is the generator deterministic?
No, and it shouldn't be. Determinism would defeat the purpose.

Conclusion

See also: Generating Cryptographically Secure Passwords in the Browser, Cypress + YoBox, Realistic Mock Data.

Rotation strategies

Per-run rotation is the default. For shared seed users that need to survive across days, rotate weekly via a scheduled CI job that regenerates the password and updates the secret store.

رVault integration
Pipe generated passwords directly into HashiCorp Vault, AWS Secrets Manager, or 1Password CLI so they're never persisted in plain text on a developer's machine.

\\bash
op item create --category=login --title="QA-bot" \
--vault=QA password="$(yobox-genpass 24)"
\\

Audit trails

For SOC 2 evidence, log that a password was generated and when, never what. The generator runs entirely client-side, so the audit trail lives in your CI logs or your secret store's access history.

Migration from hardcoded fixtures

Grep for any string matching common weak-password regexes and replace with a runtime call to the generator. A one-day refactor that removes an entire category of audit findings.

Why test credentials deserve real entropy

Most teams treat test credentials as throwaway strings and end up reusing the same five passwords across staging, CI, and local dev. That works right up until the day a staging dump leaks, an intern pushes a .env.test to a public repo, or a screen recording captures Password123! on a login form during a demo. Treating every credential — even "fake" ones — as if it could escape into the wild is the only sustainable habit.

The YoBox Password Generator produces high-entropy strings on the client using crypto.getRandomValues. Nothing is sent to a server, nothing is logged, and nothing is cached. That property matters for compliance-adjacent teams who need a defensible answer to "where did this password come from?"

Practical use cases

Seeding ephemeral users in E2E tests Pair the generator with Cypress or Playwright. Generate one credential per test run, store it in a closure (never in a fixture file), and discard it when the suite finishes.

// playwright/fixtures/user.ts
import { test as base } from "@playwright/test";

export const test = base.extend<{ creds: { email: string; password: string } }>({
creds: async ({}, use) => {
const password = crypto.getRandomValues(new Uint8Array(24))
.reduce((s, b) => s + "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!@#$%^&*"[b % 70], "");
const email = qa+${Date.now()}@yobox.dev;
await use({ email, password });
},
});

Bootstrapping local dev databases When a developer joins the team, the onboarding script should generate a per-machine database password instead of shipping a default. Pipe the output of the generator into your .env.local template:

yobox-pass --length 32 --symbols >> .env.local

CI secret rotation drills Quarterly rotation drills feel theoretical until you actually do one. Use the generator to produce candidate values, store them in your secret manager, redeploy, and verify nothing breaks. The drill itself is the deliverable.

Length, character classes, and entropy

Length Character set Approx. entropy Use case
12 letters + digits ~71 bits Throwaway test logins
16 letters + digits + ! ~104 bits Shared dev environments
24 full symbols ~157 bits Service accounts
32 full symbols ~210 bits Root / break-glass
Anything below 70 bits is fine for transient test accounts that exist for one CI run. Anything that survives the run should be 100+ bits.

Storing test credentials safely

Never commit .env files, even ones suffixed with .test or .example if they contain real values.
Use your CI provider's encrypted secrets (GitHub Actions encrypted secrets, GitLab CI variables, Render environment groups).
Rotate every credential that appears in a screen-share, demo recording, or screenshot — assume it is compromised.
For E2E suites, prefer generated-per-run credentials over static fixture users. Static users invite bypass code that ships to production.

Troubleshooting

The generated password is rejected by my signup form.
Most forms enforce a regex like ^(?=.[A-Z])(?=.\d)(?=.*[!@#$]). Generate with mixed character classes enabled and re-test.

Special characters break my shell.
Wrap the value in single quotes or pipe through base64 for transport. Better: read the value from stdin in your tooling so the shell never sees it.

My password manager refuses to autofill.
This usually means the form sets autocomplete="off" or uses a non-standard input type. Use the manager's manual fill, then report the form to the vendor.

FAQ

Is the generator safe for production secrets?
It is cryptographically sound, yes — but production secrets should be generated and stored inside your secret manager (AWS Secrets Manager, Doppler, 1Password CLI) so rotation and audit logging are first-class. The generator is ideal for ad-hoc and test use.

Does YoBox log generated passwords?
No. Generation happens entirely in the browser. The page never makes a network request when you click Generate. You can verify this in DevTools → Network.

Can I script the generator?
The web UI is the official surface. For scripting, mirror the algorithm with a one-liner using crypto.getRandomValues in Node 19+ or the equivalent in your language of choice.

How does it compare to other generators?
Tool Client-side No tracking Symbol control Free
YoBox Password Yes Yes Yes Yes
1Password Yes Yes Yes Paid
Random "password" sites Sometimes Often no Limited Yes
Where do I plug this into my workflow?
Pair it with the Webhook Tester for webhook signing secrets, with Temp Mail for end-to-end signup tests, and with the Regex Assistant when you need to validate that your generated values match your application's password policy.

Comparison: credential strategies for test suites

Strategy Entropy CI-safe Audit-friendly Maintenance
Hardcoded Password123! ~30 bits No No Zero, until the audit
Shared .env file Variable Risky — leaks via logs No Manual rotation
Per-run generated via YoBox Password Generator 128+ bits Yes Yes None
Vault-backed dynamic secrets 128+ bits Yes Yes (best) Vault setup
A test credential is a production credential that hasn't leaked yet. Treat both with the same generation pipeline and you remove an entire class of incidents from your roadmap.

Real use cases

Cypress per-spec users
Mint a unique 24-character password at the top of each spec, sign up a new user against a YoBox inbox, then run the flow. Nothing persists, nothing shares state, and parallel workers never collide. Wire-up details live in the Cypress + YoBox guide.

Playwright global setup
For suites that prefer a stable authenticated state, generate one strong password during globalSetup, store it via storageState, and replay it across every worker. The Playwright + YoBox guide shows the parallel-safe pattern, and the credential itself comes from the same generator covered in Generating Cryptographically Secure Passwords in the Browser.

Postman / Newman environments
Use a pre-request script to call the generator, set pm.environment.set("password", value), then reference {{password}} in subsequent requests. The credential never lands in the collection JSON, so the file remains safe to commit. The Postman + YoBox guide covers the assertion side.

Docker-based CI matrices
When your CI runs against the Docker Builder Guide stack, mint credentials inside the runner container and export them as environment variables for the test process only. Containers are ephemeral; credentials die with them.

Key takeaways

Generate fresh credentials per CI run by default; promote to shared only when a test genuinely requires persistence.
Use the YoBox Password Generator or crypto.getRandomValues directly — never Math.random, never a hand-typed string.
Combine generated credentials with disposable Temp Mail addresses to keep the entire test identity ephemeral.
Validate complexity assertions with patterns from the Regex Patterns cheat sheet.
Log that a credential was generated, never what — your audit trail belongs in CI metadata, not stdout.
Static test credentials are the password equivalent of TODO: remove before launch. They never get removed, and they always show up in the breach report.

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.

Cypress E2E with YoBox: Disposable Email + Webhook Tester

yobox — Sat, 20 Jun 2026 17:10:37 +0000

Learn how to test signup flows, OTP verification, password resets, and webhook events end-to-end using Cypress with disposable email inboxes and real-time webhook inspection.

The two flows every SaaS app has, and the two flows almost every Cypress suite stubs out, are signup with email verification and outbound webhooks. Stubbing those is convenient. It's also exactly why your QA team finds bugs in production that the suite missed. YoBox gives Cypress a real disposable inbox and a real webhook receiver — both over plain HTTP — so you can test the full round-trip without ngrok, without a shared mailbox, and without a single environment variable that needs rotating.

This walkthrough builds a complete e2e suite from scratch.

What you'll build

By the end of this article you'll have:

A Cypress project wired to the YoBox Temp Mail and Webhook Tester endpoints.
A signup → OTP → onboarding test that runs against your real backend.
A billing → webhook test that asserts payload shape, not just delivery.
A CI configuration that runs four shards in parallel with zero shared state.

Install and wire up

npm i -D cypress cypress-wait-until
cypress.config.js:

const { defineConfig } = require("cypress");

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

cypress/support/e2e.js:

import "cypress-wait-until";

Test 1 — Signup with email OTP

describe("Signup", () => {
it("verifies a brand-new user with OTP", () => {
cy.task("newInbox").then((inbox) => {
cy.visit("/signup");
cy.get("[data-test=email]").type(inbox.address);
cy.get("[data-test=password]").type("StrongPass!42");
cy.get("[data-test=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((d) => {
const otp = d.messages[0].text.match(/\b\d{6}\b/)[0];
cy.get("[data-test=otp]").type(otp);
cy.contains("Verify").click();
cy.url().should("include", "/welcome");
});
});
});
});

The test creates a never-before-used email, walks the signup form, polls for the OTP, types it, and asserts the redirect. No mocks. No shared inbox. Safe to run in parallel.

Test 2 — Webhook delivery

describe("Billing", () => {
it("delivers invoice.paid to the partner webhook", () => {
cy.task("newHook").then((hook) => {
cy.visit("/admin/integrations");
cy.get("[data-test=callback]").clear().type(hook.url);
cy.contains("Save").click();
cy.contains("Send test invoice").click();

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

cy.task("readHook", hook.id).then((d) => {
const req = d.requests[0];
expect(req.method).to.eq("POST");
const body = JSON.parse(req.body);
expect(body.event).to.eq("invoice.paid");
expect(body.data.amount_cents).to.be.greaterThan(0);
});
});
});
});

That second expect — payload shape — is the assertion that actually prevents regressions.

Test 3 — Magic-link auth

The pattern generalizes. Magic links are just OTPs that happen to be URLs.

cy.task("readInbox", inbox.id).then((d) => {
const url = d.messages[0].text.match(/https?:\/\/\S+/)[0];
cy.visit(url);
cy.url().should("include", "/dashboard");
});

Comparison: stubbed vs YoBox

Aspect Stubbed email YoBox disposable inbox
Catches SMTP regressions No Yes
Tests real template No Yes
Parallel-safe Yes (trivially) Yes
CI setup None One env var
Production fidelity Low High
Free tool
Open Cypress Guide
End-to-end recipes for Cypress + YoBox.

Open
The same table applies to webhook stubs vs the Webhook Tester.

CI

jobs:
cypress:
strategy:
matrix: { shard: [1, 2, 3, 4] }
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: cypress-io/github-action@v6
with:
parallel: true
record: true
group: e2e-${{ matrix.shard }}
env:
CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }}
YOBOX: https://yobox.dev/api
Add the Docker Builder recipe if you want fully containerized runs.

Helpers worth promoting to your support folder

`js // cypress/support/commands.js Cypress.Commands.add("newUser", () => cy.task("newInbox").then((inbox) => ({ email: inbox.address, inboxId: inbox.id, password: Test!${Date.now()},
}))
);

Cypress.Commands.add("readOtp", (inboxId) =>
cy.task("readInbox", inboxId).then((d) => d.messages[0].text.match(/\b\d{6}\b/)[0])
);
`javascript

Now any spec reads like English:

cy.newUser().then((u) => {
cy.visit("/signup");
cy.get("[data-test=email]").type(u.email);
// ...
});

Pairs nicely with

Password Generator for strong test credentials.
Regex Assistant for tuning extraction patterns.
Lorem Ipsum for realistic form fixtures.

Common pitfalls

cy.wait(5000). Use cy.waitUntil against the YoBox endpoint — fail fast on real signal.
Regex that catches the year. Anchor OTP regex with \b\d{6}\b.
Forgetting to assert webhook shape. Count > 0 is a smoke test; shape assertion is the regression test.
Re-using an inbox across tests. Each test should ask for its own — it's cheap and avoids cross-test leakage.

FAQ

Does this work with cy.session?
Yes — cache the verified session per test user. Each user still gets their own YoBox inbox.

Can I download attachments?
Yes; the messages endpoint exposes attachment metadata.

What about non-ASCII email bodies?
The plain-text part is UTF-8; text.match(...) handles emoji and CJK fine.

Do I need a paid plan for parallelization?
YoBox is free. Cypress's Dashboard parallelization needs a record key.

Conclusion

YoBox turns Cypress into a test runner that can honestly exercise every flow your users actually hit — signup, OTP, magic links, billing, partner webhooks — without stubs, without ngrok, and without shared state. Wire up the four tasks, write two specs, and you're already covering ground most QA suites never reach.

Further reading: The Complete Cypress + YoBox Guide, Playwright Automation with YoBox, and Realistic Mock Data.

Advanced: combining inbox + webhook in one test

Some flows depend on both — a signup that sends an email and notifies a partner via webhook. Provision both resources in \beforeEach\ and assert both at the end.

\\js
beforeEach(() => {
cy.task("newInbox").as("inbox");
cy.task("newHook").as("hook");
});
\\

Retries and flake control

\retries: { runMode: 1, openMode: 0 }\ in \cypress.config.js\ absorbs single-request network blips in CI without masking real bugs locally. Combined with YoBox's high-availability polling endpoint, this brings practical flake rate to under 0.5%.

Long-running integration tests

For tests that span minutes — invoice cycles, scheduled jobs — increase the YoBox poll timeout to 5 minutes and add a progress log every 30 seconds so CI doesn't appear hung.

Migration playbook

Replace the shared QA inbox with a per-test YoBox inbox in one PR. Replace the staging webhook URL with a YoBox hook in the next. Each PR is a clean refactor with a tiny diff and an immediately visible flakiness drop.

A complete Cypress + YoBox setup

The pattern below is what we ship in production for E2E flows that touch real email and real webhooks.

cypress.config.ts
`ts
import { defineConfig } from "cypress";

export default defineConfig({
e2e: {
baseUrl: process.env.BASE_URL ?? "http://localhost:3000",
setupNodeEvents(on) {
on("task", {
async "yobox:newInbox"() {
const r = await fetch("https://yobox.dev/api/mail/new", { method: "POST" });
return await r.json(); // { address, token }
},
async "yobox:pollOtp"(token: string) {
const deadline = Date.now() + 30_000;
while (Date.now() < deadline) {
const m = await fetch(https://yobox.dev/api/mail/${token}/latest).then(r => r.json());
const code = m?.text?.match(/\b\d{6}\b/)?.[0];
if (code) return code;
await new Promise(r => setTimeout(r, 1000));
}
throw new Error("OTP timeout");
},
"yobox:newHook"() {
const id = crypto.randomUUID();
return { id, url: https://yobox.dev/api/hooks/${id} };
},
async "yobox:pollHook"(id: string) {
const r = await fetch(https://yobox.dev/api/hooks/${id}).then(r => r.json());
return r.requests ?? [];
},
});
},
},
});
`

Custom commands
// cypress/support/commands.ts
Cypress.Commands.add("waitForHook", (id: string, ms = 15000) => {
const start = Date.now();
const check = (): any => cy.task("yobox:pollHook", id).then((reqs: any[]) => {
if (reqs.length) return reqs[0];
if (Date.now() - start > ms) throw new Error("Webhook timeout");
return cy.wait(500).then(check);
});
return check();
});
Signup spec
describe("signup with real OTP", () => {
it("verifies a generated code", () => {
cy.task("yobox:newInbox").then((inbox: any) => {
cy.visit("/signup");
cy.get("[name=email]").type(inbox.address);
cy.contains("button", /send code/i).click();
cy.task("yobox:pollOtp", inbox.token).then((code: string) => {
cy.get("[name=otp]").type(code);
cy.contains("button", /continue/i).click();
});
cy.contains(/welcome/i).should("be.visible");
});
});
});
Webhook spec
describe("integration webhook", () => {
it("delivers a payload to a YoBox URL", () => {
cy.task("yobox:newHook").then((hook: any) => {
cy.visit("/integrations/new");
cy.get("[name=webhookUrl]").type(hook.url);
cy.contains("button", /save/i).click();
cy.contains("button", /send test event/i).click();
cy.waitForHook(hook.id).then((req: any) => {
expect(req.method).to.eq("POST");
const body = JSON.parse(req.body);
expect(body.event).to.eq("integration.test");
});
});
});
});

CI/CD

Run Cypress in GitHub Actions with the official action and split across workers:

jobs:
cypress:
runs-on: ubuntu-latest
strategy:
matrix: { containers: [1, 2, 3, 4] }
steps:
- uses: actions/checkout@v4
- uses: cypress-io/github-action@v6
with:
parallel: true
record: true
group: "PR-${{ github.event.pull_request.number }}"
env:
CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }}
For dockerized runs, see the Docker builder for Cypress and Playwright CI.

Cypress vs. Playwright for this workflow

Concern Cypress Playwright
Polling external API mid-test cy.task Direct fetch
Multi-tab signup → admin approval Workaround Native
Time-travel debugging Yes (best in class) Trace viewer
Parallel runs Dashboard / OSS sharding Built-in
Onboarding curve Lower Slightly higher
If your team already invests in the Cypress dashboard, stick with Cypress. If you're starting fresh and need multi-context flows, Playwright wins.

Troubleshooting

cy.task returns undefined.
Tasks must return non-undefined values. Wrap polling helpers so they return null instead of undefined on miss.

OTP test passes locally, flakes in CI.
Increase the OTP polling deadline (CI mail delivery is slower) and ensure parallel workers each create their own inbox.

Webhook test flakes.
You're either reusing a hook ID across runs or your app isn't waiting for save confirmation before firing the test event. Always assert "saved" before triggering.

FAQ

Can I use YoBox without cy.task?
Yes — cy.request works for the same endpoints, but cy.task keeps secrets and polling logic out of the browser context, which is cleaner.

How do I retry the OTP poll only?
Wrap the task call in Cypress.Promise and recurse with a max-attempts counter, or move the loop into the Node task as shown above.

Does YoBox bill per inbox?
No. The disposable inbox and webhook endpoints are free for normal CI usage. If you have unusually high volume, ping us.

Where can I see real-world usage?
See the companion guides for Playwright, Postman, and realistic mock data.

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.