60323: Challenge expired

This error occurs when a Verify Challenge expires before it is approved or verified. Twilio returns HTTP 403. Challenges are used with push and totp factors. A Challenge expires at expirationDate. If you do not set expirationDate, Twilio sets it to five minutes after creation. You can set expirationDate to at most 60 minutes after creation.

• The user did not respond to the Challenge before expirationDate.
• Your application used the default Challenge lifetime and the user needed more than five minutes to approve or verify it.
• Your application tried to verify a Challenge after its status had already changed from pending to expired.
• For a push Challenge, the device did not receive or surface the approval request in time.
• For a totp Challenge, the code in authPayload was submitted after the Challenge had already expired.

• Create a new Challenge and ask the user to approve or verify the new request.
• If your approval flow needs more time, set expirationDate when you create the Challenge. Keep the value within 60 minutes of creation.
• Check the Challenge status before prompting the user to respond. If the status is expired, stop the current flow and create a new Challenge.
• For push flows, implement polling for pending Challenges when the app opens. Use push notifications as an added convenience, not as the only way the app learns about a new Challenge.
• If a user does not receive the first push notification and the Challenge is still valid, request another notification for the same Challenge with the Notifications resource. If the Challenge has already expired, create a new Challenge instead.
• For totp flows, prompt the user to enter the code immediately and create a new Challenge if the current one has expired.

• Challenge resource
• Notifications resource
• Verify Push and Silent Device Approval Best Practices for Production use