The SMS code arrived. Why can’t my customer sign in?

Check which ID your sign-in form is using

A successful call to POST /api/v1/otp returns two IDs. The uuid identifies the text message. The guid identifies the code request. Save the guid on your server with the customer’s sign-in attempt. When they submit the form, send that ID and the code they typed as otp to POST /api/v1/otp/verify using the same API account.

If you accidentally pass the message ID, the text can arrive and the code can be typed perfectly, but the pair won’t match.

Read the response before asking for another code

An HTTP 200 alone doesn’t mean the code matched. Check the response body on your server:

• {"Verified":1}: The code matched. If sign-in still fails, check what your app does next, such as whether it creates the customer’s session.
• {"Verified":0}: No match for that account, request ID and code. Check which request the form is tied to, especially if the customer asked for another text.
• must provide guid or must provide otp: The field is missing or too short. Inspect how your server builds the verification request. Sending another text won’t fix a missing field.

Test two texts arriving out of order

On a test phone, request a code, then tap “Send again.” Each successful send has its own guid. Have your app keep only the newest request active for that sign-in. Enter the first code: it should fail against the second request. Enter the second code: it should match. Enforce an expiry and close the attempt in your app after a successful sign-in.

For a support ticket, include the time of the send, the message ID and the verification result. Leave out the code and your API token. If neither text arrived, investigate the send response and delivery status first.