A logistics platform we run needed phone-number login for clients across the UK and Bulgaria. The auth layer is Supabase; the SMS provider that could deliver a branded alphanumeric sender in both markets is Infobip. The problem: Infobip isn’t one of Supabase’s native SMS providers.
The clean path is the one Supabase actually provides for this: the Auth send-SMS hook. Instead of picking a provider from the dropdown, you register an edge function that receives the OTP payload and owns delivery. Ours normalises the number to E.164 (default +44, one tap to +359, local formats accepted), calls Infobip’s API with the branded sender, and returns delivery state to the auth flow. Email OTP sits beside it as a fallback that works before any SMS regulation clears.
The part nobody tells you about is the regulatory queue, not the code. A branded sender name is a per-country registration: the UK route went live after template whitelisting; the Bulgarian queue is its own operator process with its own timeline. Ship the architecture early, treat sender registration as a project dependency with a date, and keep the email path first-class so login never blocks on a telecoms approval.
The doctrine we took away: when a platform doesn’t support your provider, look for the extension point before you look for a workaround. The hook is the supported contract — it survives upgrades. The workaround wouldn’t.