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 this through the Twilio managed connector inside the project that needs 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 code lifecycle. You never generate, store, expire, or compare the digits yourself. Twilio sends and checks the code and returns its verification status. You still configure current service limits and application-level abuse controls.
"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, hands the verified phone identity to the reviewed server-side account/session flow you deploy. If you use Supabase, the generated plan must use a supported Supabase auth mechanism; the client-provided phone number is never treated as proof by itself.
- Handles the awkward bits: resend with a cooldown, wrong-code messaging, and expiry.
Because Verify owns code generation, expiry, and verification status, you avoid storing passcodes in your own database. You must still configure Twilio's current service limits and add application-level abuse controls before launch.
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 uses an Account SID plus either an Auth Token or an API Key SID and secret. Verify also uses a Verify Service SID. Auth Tokens and API-key secrets are server secrets; a credential with sending permission can spend your money. They can never be bundled into an app people download.
Twilio is therefore one of the secret-key connectors. The generated app must call a narrow server-side relay, and the secret never lands in the client. Saved connector credentials are encrypted on Appsanic's side; browser JavaScript receives only presence flags, and the model prompt never receives the decrypted value.
The connector accepts a dedicated Restricted API Key for validation, or an Auth Token as a fallback. Its non-mutating check proves authentication/account binding only, not send or Verify permission. The agent can generate a Supabase Edge Function or another relay and tell you which runtime values it expects. You deploy it and add a different Restricted API Key SID and secret, the Account SID, and any Verify Service SID directly to that backend's secret manager. Give the runtime key only the Messaging and/or Verify operations the relay actually uses. Saved connector values are never copied there. See Connectors Overview.
Find the Account SID and fallback Auth Token in the Twilio Console, create Restricted API Keys in its API keys section, and create the Verify Service SID under Twilio Console → Verify → Services. Open the Appsanic project build and select Connectors → Twilio; the setup guide lists the exact validation-key permission.
A note on cost
Twilio, carrier, Verify, registration, and WhatsApp charges vary by destination, sender type, message encoding, and current provider policy. Review the current Twilio pricing for every launch country. Configure geographic permissions, provider-side usage triggers, per-user and per-destination rate limits, and an application-level daily cap; monitor delivery and spend from the first staging test onward.
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.
- Sender registration. Some destinations and sender types require registration or approved templates. Check Twilio's current country-specific rules before launch and allow time for provider review.
- Trial-account limits. Trial restrictions change. Check the current account status, allowed recipients, sender capabilities, and messaging limits before treating a staging result as production-ready.
- 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 only the result needed by the server-side account flow. Configure Verify and application-level rate limits explicitly; the connector test does not validate them.
- The relay is a small piece of server code holding the Account SID, a dedicated Restricted API Key SID and secret, and any Verify Service SID in its environment. The downloadable app talks only to the authenticated relay. The agent can generate the function, but you deploy it, provision those runtime values separately, and test the exact permissions in staging.
- Session creation happens only after Verify returns an approved result and the server validates it. The verified identity then enters the app's reviewed account/session flow. A Supabase integration must use a currently supported server-side auth design; it must not mint an improvised client session or trust a phone number supplied by the app.
- 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.