POST/api/public/access-request/email/start-verification

Odešle 6místný, 10 minut platný potvrzovací kód na zadanou e-mailovou adresu — první krok před žádostí o přístup.

`POST /api/public/access-request/email/start-verification` spouští e-mailovou verifikaci pro veřejnou žádost o přístup. Požadavek nevyžaduje přihlášení a obsahuje kontrolovanou adresu v poli těla `email`. Při úspěšném zpracování systém odešle šestimístný potvrzovací kód, který je platný deset minut. Odpověď obsahuje `ok`, `verification_id`, `expires_in_minutes` a `resend_cooldown_seconds`. `verification_id` musí být použita společně se stejnou e-mailovou adresou a přijatým kódem v navazující ověřovací trase. Není to přihlašovací token a nesmí být uložena jako trvalý identifikátor uživatele ani veřejně zaznamenávána. Endpoin není idempotentní. Více úspěšných volání může vytvořit více ověřovacích procesů nebo nové kódy. Proto platí přísný limit založený na IP adrese: deset požadavků během 15 minut. Odpověď navíc upozorňuje na blokaci opakování po dobu 60 sekund. Rozhraní by během této doby nemělo spouštět nové odeslání a mělo by srozumitelně zobrazovat zbývající čekací dobu. Pokud je limit překročen, trasa odpoví `429 RATE_LIMIT_EXCEEDED`. Pokud kód nelze odeslat kvůli chybě doručení, je zdokumentováno `502 MAIL_NOT_SENT`. Tyto případy je třeba řešit odděleně: rate limit se vyřeší čekáním, chyba e-mailu vyžaduje dosažitelnou adresu a fungující doručování. Tajemství nebo interní údaje o poštovním serveru nepatří do chybové zprávy. Případ úspěchu byl živě ověřen se skutečným `verification_id`. Přidružená zpráva byla přijata prostřednictvím vlastního falešného SMTP serveru a šestimístný kód byl přečten z reálného obsahu e-mailu. Rovněž byl po opakovaných voláních pozorován negativní případ 429. Právě toto potvrzení lze uvést; z něj ještě nevyplývá úspěšně dokončená žádost o přístup ani platební transakce.

{"email":"max@example.com"}

{"ok":true,"verification_id":"<UUID>","expires_in_minutes":10,"resend_cooldown_seconds":60}