Should your app send sign-in codes by SMS or WhatsApp?
Both channels put a code on your customer’s phone. The choice changes what your server needs to do when the customer types it back in.
With SMS, the request ID connects the two steps
Say a customer wants to sign in to view a reservation. Your server calls POST /api/v1/otp with their mobile number. SMS Studio generates the one-time password and sends it by text. Save the guid from the successful response with that sign-in attempt.
When the customer enters the code, send it as otp with the same guid to POST /api/v1/otp/verify. Continue sign-in when the response contains "Verified": 1. This flow suits an app that wants SMS Studio to handle both generating and checking the code.
With WhatsApp, your app owns the code
If your app already issues codes and sets their expiry, it can use WhatsApp for delivery. Your server supplies the phone number and its own code to POST /api/v1/whatsapp/otp. Before offering that option, confirm account access, destination pricing and an approved authentication template for the language you need.
Save the returned message uuid if you want to match delivery updates to the request. A delivered update tells you the message reached WhatsApp. To finish sign-in, your own server must still check the entered code against the active attempt.
Decide what “Text me instead” should do
Offering both buttons gives the customer a choice. SMS Studio doesn’t automatically send an SMS when a WhatsApp message fails. If the customer chooses the SMS option, start the SMS flow and save its new guid. Show which channel sent the code the form now expects.
For a sign-in test, try entering the WhatsApp code after switching to SMS. Your form should use the verification flow tied to the current attempt. The WhatsApp message ID is for delivery tracking and cannot stand in for an SMS verification request ID.