Skip to content
CyberTemp
All posts
Wire CyberTemp into your signup-flow tests in under 10 lines

Wire CyberTemp into your signup-flow tests in under 10 lines

CyberTemp6 min read

If your signup flow has an OTP step or a "click the link in your email" confirmation, it's almost certainly broken in one of your CI runs right now and nobody knows. The reason is simple: your test environment doesn't have a real inbox to read from, so the test either skips the email step entirely or mocks it out. Mocking is fine until the day the real provider changes a template field and your handler trips on a parse step the mock never exercised.

CyberTemp solves that with a flat HTTP API that gives a test runner a real inbox to poll. The whole integration is under ten lines in any language.

The minimum viable wiring

Here's what the test needs to do:

  1. Pick or create a throwaway address.

  2. Submit the signup form (via Playwright, Cypress, requests, whatever).

  3. Poll GET /getMail for that address until the verification mail lands.

  4. Pull the OTP code or magic link out of the message body.

  5. Use it to finish the signup.

Step 1 is free — GET /getMail?email=<anything>@cybertemp.xyz implicitly creates the inbox on first read. There's no separate create call. You don't even need to plan the address ahead of time; a UUID-based local-part works fine.

Python — a real end-to-end snippet

import os, time, uuid, re, requests

API_KEY = os.environ["CYBERTEMP_API_KEY"]  # starts with tk_
HEADERS = {"X-API-Key": API_KEY}


addr = f"qa-{uuid.uuid4().hex[:8]}@cybertemp.xyz"


Trigger your signup flow with addr as the email.


... your existing code that fills the form / hits your API ...


Poll for the OTP mail.


deadline = time.time() + 30
while time.time() < deadline:
r = requests.get(
"https://api.cybertemp.xyz/getMail",
headers=HEADERS,
params={"email": addr},
timeout=5,
)
msgs = r.json()
if msgs:
body = msgs[0].get("body") or msgs[0].get("html") or ""
match = re.search(r"\b(\d{6})\b", body)
if match:
otp = match.group(1)
break
time.sleep(1)
else:
raise TimeoutError("OTP did not arrive in 30s")


Use otp to finish the signup.

That's the whole thing. No webhook receiver to stand up, no SMTP server to spin up in a sidecar container, no shared fixture mailbox where two parallel test runs collide.

Why this beats the alternatives

The three patterns most teams reach for instead:

  • Mock the email step. The fastest to write, the worst at catching real regressions. Your template parser, your link tokenizer, your "if user clicks magic link within 5 minutes" timing — none of it is under test. The mock confirms the function you wrote agrees with itself.

  • Use a shared QA Gmail. Works once, then breaks the day someone runs the suite in parallel, or the day Google starts requiring 2FA, or the day the test creds end up in a screenshot. Also: shared accounts have shared inboxes, and you'll spend half your time scrolling past mail from yesterday's run.

  • Spin up a local SMTP catcher. Reasonable for unit-style tests where your code talks to the SMTP server directly. Useless for end-to-end tests against the deployed app, because the deployed app sends mail through your real provider — SendGrid, Postmark, SES, whoever — and your local catcher never sees it.

CyberTemp sits where you actually need a test inbox: receiving real mail, from your real provider, to a real address, that nobody else's run is touching at the same time.

Per-test isolation, for free

The UUID local-part pattern gives every test run its own inbox. No setup, no teardown — when the test finishes, you can either let the inbox expire on its own or delete it explicitly with DELETE /inbox?email=<addr> to free a slot against your plan limit. Either way, the next run starts on a fresh address and there's no cross-contamination between parallel jobs.

That matters more than it looks. The most common reason flaky email tests stay flaky is that the previous run's mail is still sitting in the inbox when the next run polls, so the test sees a stale OTP and proceeds with a code that's already expired. Per-run inboxes make that class of bug structurally impossible.

Magic links, not just OTPs

Same shape. Instead of regex-matching a six-digit code, regex-match the verification URL out of the body, then have Playwright navigate to it:

match = re.search(r"https://your-app\.com/verify\?token=[A-Za-z0-9_-]+", body)
if match:
verify_url = match.group(0)
page.goto(verify_url)

The body of the message is the same — it's just a question of what pattern you pull out of it. Magic link, OTP code, confirmation token, password reset link, invite acceptance URL — all of them are some kind of token in some kind of message body, and the polling shape is identical.

What you don't have to think about

A few things CyberTemp handles so you don't:

  • The address doesn't need to be pre-registered. Your test makes one up, hits the endpoint, and the inbox exists.

  • Rate limits are per-key, not per-inbox. Spawn a thousand inboxes in a test matrix — your key's rate limit governs the polling, not the address count.

  • Mail lands fast. There's no "wait 30 minutes for the relay to catch up" surprise. If your provider sent it, it's there within a couple of seconds of arrival.

  • The API is a flat set of GETs and DELETEs. No webhook setup. No SDK install required (though Go and Rust SDKs exist if you'd rather use them than raw HTTP).

Plan sizing for a test suite

If your suite is small — a few signup-related tests, run a few times a day — the FREE tier covers it. As suites grow, the limiting factor is concurrent inbox count, not request volume. ECO ($1.99/mo) and CORE ($2.99/mo) raise both the inbox slot count and the per-month request ceiling; ELITE ($4.99/mo) is sized for high-throughput automation pipelines where you're running large parallel matrices and don't want to count requests at all. The pricing page has the exact numbers.

Bottom line

End-to-end signup-flow tests are the ones most teams have a gap on, because setting up a real test inbox feels like more work than it's worth. With CyberTemp it's literally a requests.get with a UUID address — under ten lines, no infra, no shared state, no expired-OTP flakes. The first test you wire up will probably catch a parsing bug your mocks have been hiding for six months.

Get an API key from cybertemp.xyz, paste it into your CI secrets, and your next signup-flow test can be the first one that actually exercises the email step.

Share