SMS & Phone Verification
Some apps want a phone number, not an email. Marketplaces verifying real people, delivery apps texting a courier's ETA, anything where "enter the code we just texted you" is the natural way in. The agent wires all of this up through the Twilio managed connector. You connect Twilio once in Dashboard → Connectors → Twilio, and every project in your account can use it.
This complements the email, social, and magic-link sign-in covered in Authentication. Phone-OTP is just another way for a user to prove who they are. You can run it alongside the others or on its own.
Phone-OTP sign-in (the recommended path)
The cleanest way to do "text me a code" is to let Twilio's Verify service own the whole code lifecycle. You never generate, store, expire, or check the six digits yourself. Twilio sends the code, remembers it, enforces the expiry and retry limits, and tells your app a single thing: was the code the user typed correct, yes or no.
"Let people sign in with their phone number. Text them a six-digit code through Twilio Verify, check it on the next screen, and create or sign in the Supabase user once the code is correct."
What the agent does:
- Builds the two screens: enter your phone number, then enter the code.
- Calls Twilio Verify to start a verification (Twilio sends the SMS).
- Calls Twilio Verify again to check the code the user typed.
- On a correct code, creates or signs in the matching user in your Supabase database and starts their session.
- Handles the awkward bits: resend with a cooldown, wrong-code messaging, and expiry.
Because Verify owns the code, you avoid the classic home-grown mistakes - codes that never expire, codes you can brute-force, codes sitting in a database table in plain text. It is the safer default, so the agent reaches for it unless you ask otherwise.
Sending transactional SMS
Separate from sign-in, you often just want to send someone a text. Order confirmations, an "your driver is 2 minutes away" ping, an appointment reminder.
"Text the customer 'Your order #1234 is on its way' when an order's status changes to dispatched. Send it through Twilio from our registered number."
The agent wires the send through the relay (see Under the hood) so the request happens server-side, triggered by the right event in your app.
A few habits worth keeping:
- Keep transactional texts transactional. A code, a receipt, a status update. Marketing SMS has its own consent and opt-out rules in most countries, and carriers police it hard.
- Always offer a way out. For any non-essential messaging, honour STOP and keep a suppression list so you never text someone who opted out.
- Mind the length. A single SMS segment is 160 characters (fewer if you use emoji). Longer messages split into multiple segments, and you pay per segment.
WhatsApp (optional)
Twilio can also send through WhatsApp, which is the better channel in many regions and supports richer templates. It is opt-in and needs extra setup on Twilio's side (a WhatsApp sender and pre-approved message templates for anything outside a 24-hour reply window).
"Send the booking confirmation over WhatsApp through Twilio instead of SMS, and fall back to SMS if the user isn't on WhatsApp."
Ask for it and the agent writes the WhatsApp send path. You complete the sender registration and template approval inside your Twilio account.
Twilio is a secret-key connector
This is the part worth understanding. Twilio gives you an Account SID, an Auth Token, and (for Verify) a Verify Service SID. The Auth Token is a secret - anyone holding it can send messages and spend your money. So it can never be bundled into an app that people download.
Twilio is therefore one of the secret-key connectors. Like OpenAI, Anthropic, Replicate, and Expo Push, the generated app never talks to Twilio directly. Instead it calls a small server-side relay that holds the credentials in its own environment, and the secret never lands in the app. The AI never sees the decrypted secret either - your connector credentials are encrypted on our side, and the browser only ever sees that a key exists.
When Supabase is connected, Appsanic can deploy that relay for you as a Supabase Edge Function. You paste the Account SID, Auth Token, and Verify Service SID into your Supabase secrets, following the instructions the agent generates. The full picture lives in Connectors Overview under "Secret keys and the tiny relay".
To find the three values: the Account SID and Auth Token sit on your Twilio Console dashboard, and the Verify Service SID is created when you add a Verify service in Twilio Console → Verify → Services. Paste them into Dashboard → Connectors → Twilio; the connector page has a "How to find your keys" pointer to the exact pages.
A note on cost
Twilio itself is pay-as-you-go, and on top of Twilio's own fee, carriers charge per message. This is real money that leaves your pocket, separate from your Appsanic credits:
- Every SMS and every Verify code costs a per-message fee that varies by destination country - texts to some countries cost many times what they cost domestically.
- A multi-segment SMS is billed per segment, so a long message can cost two or three times a short one.
- WhatsApp has its own per-conversation pricing.
A couple of guards keep the bill sane: rate-limit how often a single number can request a code (Verify does this for you), and put a sensible daily cap on any automated sending. Watch your Twilio usage dashboard for the first few weeks after you go live.
Things that go wrong
- Codes not arriving. Usually the destination number is wrong, the country isn't enabled on your Twilio account, or the carrier is filtering unregistered sender IDs. Twilio's logs show the delivery status for each message.
- A2P registration. Sending SMS to US numbers needs A2P 10DLC registration on Twilio's side before delivery is reliable. Do this early - approval can take a few days.
- Trial-account limits. A Twilio trial can only text verified numbers and prefixes a banner to every message. Upgrade before real users arrive.
- WhatsApp template rejections. Outside a 24-hour reply window, WhatsApp only allows pre-approved templates. Free-form messages will be rejected.
Under the hood (for engineers)
- Phone-OTP runs on Twilio's Verify service. The app never generates or stores the code. The relay calls Verify's start endpoint to send the code and its check endpoint to validate it, then returns a simple pass/fail to the app. Verify enforces code length, expiry, and per-number rate limits, so there is no OTP table in your database to brute-force.
- The relay is a small piece of server code holding the Account SID, Auth Token, and Verify Service SID in its environment. The downloadable app talks only to the relay, never to Twilio directly - the secret never reaches the client bundle. With Supabase connected and Account access on, the agent deploys the relay as a Supabase Edge Function and you paste the credentials into your Supabase secrets.
- Session creation happens after Verify returns a pass: the relay (or your Supabase function) looks up or creates the user keyed on the verified phone number and issues a Supabase session, so phone-OTP slots into the same auth model as the rest of Authentication.
- SMS and WhatsApp sends go through the same relay using the Twilio Messaging API, triggered by app or database events rather than directly from the client.
Next
Read Maps & Location for location-aware features like nearby search and directions.
