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

שולח קוד אימות בן 6 ספרות, בתוקף למשך 10 דקות, לכתובת הדוא"ל שצוינה — השלב הראשון לפני הגשת בקשת גישה.

`POST /api/public/access-request/email/start-verification` מתחיל את אימות כתובת הדוא״ל עבור בקשת גישה ציבורית. הבקשה אינה דורשת התחברות ומכילה את הכתובת לבדיקה בשדה `email` בגוף הבקשה. בעיבוד מוצלח המערכת שולחת קוד אישור בן שש ספרות, התקף למשך עשר דקות. התגובה מכילה `ok`, `verification_id`, `expires_in_minutes` ו-`resend_cooldown_seconds`. יש להשתמש ב-`verification_id` יחד עם אותה כתובת דוא״ל ועם הקוד שהתקבל בנתיב ה-Verify שבא לאחר מכן. זהו אינו טוקן התחברות, ואין לשמור אותו כמזהה משתמש קבוע או לרשום אותו ביומנים ציבוריים. נקודת הקצה אינה אידמפוטנטית. מספר קריאות מוצלחות עלולות ליצור מספר תהליכי אימות או קודים חדשים. לכן חלה מגבלה קפדנית מבוססת IP של עשר בקשות בתוך 15 דקות. בנוסף, התגובה מציינת חסימה של 60 שניות לשליחה חוזרת. בזמן זה הממשק לא אמור להפעיל שליחה חוזרת, ועליו להציג באופן מובן את זמן ההמתנה שנותר. בחריגה מהמגבלה הנתיב מחזיר `429 RATE_LIMIT_EXCEEDED`. אם לא ניתן לשלוח את הקוד בשל כשל במסירה, מתועד `502 MAIL_NOT_SENT`. יש לטפל במקרים אלה בנפרד: מגבלת קצב נפתרת בהמתנה, ואילו כשל דואר מחייב כתובת זמינה ומסירה תקינה. סודות או נתונים פנימיים של שרת הדואר אינם שייכים להודעת השגיאה. מקרה ההצלחה אומת בסביבה החיה עם `verification_id` אמיתי. ההודעה המתאימה התקבלה דרך שרת Fake-SMTP ייעודי, והקוד בן שש הספרות נקרא מתוכן הדוא״ל האמיתי. בנוסף נצפה מקרה השלילה 429 לאחר קריאות חוזרות. מותר לציין בדיוק הוכחה זו; אין להסיק ממנה שבקשת גישה או תהליך תשלום הושלמו בהצלחה.

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

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