Referral programs are among the most email-heavy flows products ship: a share generates a code, a referee receives an email, a signup creates attribution, and eventually two people get reward emails. Every step is a distinct failure surface, and the flow is inherently multi-mailbox — one complete test needs at least a referrer and a referee. That is precisely where disposable inboxes shine: fresh addresses per run, scripted code extraction, and none of your colleagues' personal mailboxes filling up with test invites.
Anatomy of a referral flow worth testing
Before automating anything, write down the events your product emits and what each must contain:
- Code generation: unique per referrer, sometimes per channel, with format constraints such as length, charset, and case sensitivity.
- Share email: contains the code, a personalized link with a click identifier, or both.
- Signup with the code applied: the referee clicks the link or enters the code manually — two different code paths.
- Attribution: the backend records referee to referrer, usually with an attribution window and rules for conflicts.
- Reward emails: typically two, one per party, sent when the referee completes a qualifying action — not at signup.
Most referral bugs live in the seams: the code in the email not matching the generated one, the link identifier stripped by a redirect, rewards firing at signup instead of qualification, or the two reward templates getting swapped.
The multi-inbox test workflow
1. Provision inbox A and register the referrer. [Create a temporary inbox](/), or provision accounts via API as covered in temporary email for QA test accounts. 2. Trigger the share. Use the invite-by-email path with inbox B's address as recipient. Assert the share email arrives and extract the code and link — the OTP parser pulls codes from message bodies without per-template regexes. 3. Provision inbox B as a genuinely separate inbox. Self-referral detection is one of the things under test; make sure your test catches it deliberately, never by accident of aliasing. 4. Complete the referee signup through the emailed link. The link is the attribution carrier; typing the code manually exercises a different path. Assert attribution server-side — in the database or an admin API — not just a UI badge. 5. Verify reward emails to both parties. After the qualifying action, inbox A and inbox B should each receive their own reward email. Check names, amounts, and links individually; swapped templates are a classic bug. 6. Run the negative paths: expired code, code reused past its cap, self-referral, existing-customer referee, attribution window expiry. Each should produce a clear message, not silence. 7. Repeat once with a manually entered code to cover the non-link path.
Steps one through five script cleanly for CI, and the API playground is a fast way to prototype the two-inbox choreography before it becomes a suite.
Link attribution: where referrals quietly break
The emailed link is the fragile part:
- Redirect chains — email to tracking domain to app — can drop query parameters at any hop. Capture the final landing URL in your test and assert the click identifier survived.
- First-click versus last-click: when a referee clicks two different referral links, your conflict rule decides who gets credit. Test the double-click case explicitly; almost nobody does.
- Cross-device reality: click on a phone, sign up on a laptop. Many programs drop attribution here by design; verify the documented behavior matches the implementation.
- Code normalization: case, whitespace, and zero-versus-letter-O confusion. A code that works pasted but not typed is a support-ticket generator.
Fraud-trigger pitfalls
Referral programs are aggressively fraud-patrolled, and a test loop can look exactly like abuse:
- Same-IP bursts: dozens of signups from one CI runner in minutes resemble a fraud farm. Isolate test traffic in staging, or get test accounts and IP ranges allowlisted.
- Disposable-domain blocklists: referral flows often block throwaway domains precisely because of referral abuse. Your testing tool can be blocked by the feature you are testing — expect it, and read it as a data point about your own blocklist behavior rather than a mystery outage.
- Velocity rules: rapid generate-share-signup loops per account trip velocity checks. Space automated runs, or flag accounts as test traffic where the system supports it.
- Reward caps: a referrer cap can silently stop rewarding after a set number of referees, which looks like emails stopped sending. Check counters before blaming the mail pipeline.
The failure mode to avoid: the suite gets shadow-flagged, referrals stop working for its accounts, and you start filing mail bugs that are actually fraud-system verdicts.
FAQ
How many inboxes does a referral test need? Two minimum: referrer and referee. Add a third when testing attribution conflicts — two referrers competing for one referee — and use fresh pairs each run so prior state cannot leak between tests.
How do I extract referral codes automatically? Fetch the newest message at each inbox and parse the code from the body with a dedicated parser. Asserting on the code's presence and format is far more stable than asserting on surrounding copy, which changes constantly.
Should referral tests run in CI on every commit? The happy path, yes — it is cheap with API-provisioned inboxes. Keep fraud-adjacent scenarios such as velocity and caps behind a flag or in a nightly environment where deliberately weird traffic is safe.
How do I tell a mail bug from a fraud verdict? Trace the send server-side first. If your system never queued the email, the cause is usually a rule — a cap, a blocklist, a velocity check — not the mail pipeline. Logs at the decision point beat inbox-side guessing every time.
Bottom line
Referral flows multiply email test surfaces: two parties, several messages, links that carry attribution, and fraud systems watching everything. Disposable inboxes make the multi-party setup trivial — fresh pairs per run, codes parsed programmatically, attribution asserted server-side. Test the negative paths as rigorously as the happy path; in referral systems, the unhappy paths are where the money leaks.