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

Pošlje 6-mestno potrditveno kodo, veljavno 10 minut, na navedeni e-poštni naslov – prvi korak pred zahtevo za dostop.

`POST /api/public/access-request/email/start-verification` začne preverjanje e-pošte za javno zahtevo za dostop. Zahteva ne potrebuje prijave in vsebuje naslov, ki ga je treba preveriti, v polju telesa `email`. Pri uspešni obdelavi sistem pošlje šestmestno potrditveno kodo, ki velja deset minut. Odgovor vsebuje `ok`, `verification_id`, `expires_in_minutes` in `resend_cooldown_seconds`. `verification_id` je treba skupaj z istim e-poštnim naslovom in prejeto kodo uporabiti v nadaljnji poti Verify. Ni žeton za prijavo in se ga ne sme shranjevati kot trajni identifikator uporabnika ali javno beležiti. Končna točka ni idempotentna. Več uspešnih klicev lahko ustvari več postopkov preverjanja oziroma nove kode. Zato velja strogo omejitev na podlagi IP deset zahtev v 15 minutah. Poleg tega odgovor opozarja na zaporo ponovitve 60 sekund. Vmesnik v tem času ne sme sprožiti ponovnega pošiljanja in naj razumljivo prikaže preostali čas čakanja. Če je omejitev presežena, pot odgovori z `429 RATE_LIMIT_EXCEEDED`. Če kode zaradi napake pri dostavi ni mogoče poslati, je dokumentiran `502 MAIL_NOT_SENT`. Te primere je treba obravnavati ločeno: omejitev zahtev se reši s čakanjem, napaka pošte pa zahteva dosegljiv naslov in delujočo dostavo. Skrivnosti ali interni podatki poštnega strežnika ne sodijo v sporočilo o napaki. Uspešni primer je bil preverjen v živo z resničnim `verification_id`. Pripadajoče sporočilo je bilo prejeto prek lastnega lažnega strežnika SMTP, šestmestna koda pa prebrana iz resnične vsebine e-pošte. Poleg tega je bil po ponovljenih klicih opažen negativni primer 429. Navesti je dovoljeno točno ta dokaz; iz njega še ne izhaja uspešno zaključena zahteva za dostop ali plačilni postopek.

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

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