Email a six-digit sign-in code

ALWAYS ANSWERS 202, whether or not the address has ever shopped here. A storefront's customer list is exactly what a competitor would pay to enumerate, and a response that varied by whether the address was known would hand it over one request at a time. Three mechanisms keep that true. No buyer row is created here — the shopper is created at VERIFY, once the code has been read out of a mailbox — so the database state after a request for a stranger is identical to the state after a request for a customer. There is no "does this buyer exist" read anywhere on the path, so no branch differs in cost. And every failure after validation (database, outbox, missing secret) is swallowed into the same 202, with the class logged for the operator. The one exception is a malformed address, which is a 400: that reveals nothing about who shops here, and silently accepting a typo leaves a shopper waiting for mail that was never addressable. The code is six digits from crypto/rand by rejection sampling (no modulo bias), stored only as an HMAC-SHA256 under a server secret, lives 10 minutes, is single-use, and is burned after 5 wrong attempts. At most ONE live code exists per (store, email) — a new request replaces the old one. Captcha-gated and rate-limited on two dimensions: per forwarded IP and per EMAIL. The per-email limit is the load-bearing one — the asset at risk is a mailbox, and an attacker mailbombing one address spreads across IP addresses by design.

Response Body