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

指定されたメールアドレスに6桁の10分間有効な確認コードを送信します — アクセス申請の最初のステップです。

`POST /api/public/access-request/email/start-verification` は、公開アクセスリクエストのメール検証を開始します。このリクエストには認証は不要で、検証対象のアドレスがボディフィールド `email` に含まれます。処理が成功すると、システムは6桁の確認コードを送信し、その有効期限は10分です。 レスポンスには `ok`、`verification_id`、`expires_in_minutes`、`resend_cooldown_seconds` が含まれます。`verification_id` は、その後の検証エンドポイントで、同じメールアドレスおよび受信したコードと共に使用しなければなりません。これはログイントークンではなく、永続的なユーザー識別子として保存したり、公開ログに記録したりしてはいけません。 このエンドポイントは冪等ではありません。複数の成功した呼び出しにより、複数の検証プロセスや新しいコードが生成される可能性があります。そのため、IPベースの厳格なレート制限として、15分以内に10件のリクエストまでの制限が設けられています。さらに、レスポンスには60秒間の再送クールダウン期間が示されます。UIはこの間、再送をトリガーせず、残りの待機時間をわかりやすく表示する必要があります。 制限を超えた場合、エンドポイントは `429 RATE_LIMIT_EXCEEDED` で応答します。配信エラーによりコードが送信できない場合、`502 MAIL_NOT_SENT` がドキュメント化されています。これらのケースは別々に処理する必要があります。レート制限は待機することで解消されますが、メールエラーには到達可能なアドレスと正常な配信機能が必要です。秘密情報や内部メールサーバーのデータはエラーメッセージに含めないでください。 成功ケースは、実際の `verification_id` を用いてライブで検証されました。関連するメッセージは独自のフェイクSMTPサーバーで受信され、実際のメールコンテンツから6桁のコードが読み取られました。また、繰り返し呼び出しを行った結果、429のネガティブケースも観察されました。この証明のみを言及することが許可されており、これをもってアクセスリクエストや支払い処理が正常に完了したことを意味するものではありません。

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

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