You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Supabase allows one originator to be supplied via the dashboard, but does not allow override of that originator when using the phone auth APIs. I've registered multiple originators with the same name and they work fine, but I can't add support for US phone numbers because it requires that I use a separate virtual phone number for compliance with 10DLC regulations. Any SMS to US phone numbers fails as it tries to use the default originator supplied in the dashboard.
To Reproduce
Steps to reproduce the behavior, please provide code snippets or a repository:
Setup your project using MessageBird for phone OTP
Register originators for countries that allow it, e.g. UK, most of the EU
Register a US number with 10DLC
Attempt to send an SMS to a US number while the default originator is set to the registered originators from step 2
Expected behavior
Devs should be able to override the originator. I think adding an optional value to the verifyOTP endpoint to allow an override of the default originator when a user enters a phone number from a country with specific requirements would allow devs to handle edge cases like 10DLC regs.
Screenshots
If applicable, add screenshots to help explain your problem.
System information
N/A
Additional context
I've contacted MessageBird support and they've confirmed that there is no logic for routing calls based on country inside their API, it has to be handled by the dev inside the API call.
The text was updated successfully, but these errors were encountered:
Thanks for taking the time to supply feedback. I confess I haven't used Bird so feel free to correct me the next few sentences if anything is off. My understanding is that an originator is a number so would the ideal behaviour be:
Recipient has a US phone number -> Use US number to send the message
Recipient has a number from elsewhere -> Use another number to send the message
Hey @J0 thanks for getting back to me, I'm also not an expert on this so I'm kinda just repeating a conversation I had with Bird support. What you've said above is correct for the desired behaviour, the only difference is that I use text originators registered through Bird themselves rather than phone numbers. For Supabase you might register Supabase so that people know where the SMS has come from; so:
US phone number -> Use the US number you've purchased & registered for 10DLC compliance - 10DLC docs from Bird
Elsewhere -> Use the text originator/phone number provided as default in the Supabase dashboard settings
Unsure whether any other countries have similar regulations that would require a different originator, I haven't tried registering an originator for every country as they have to be done individually; so far I've registered 24, mostly EU states, and they're all working fine using the same text originator and one default value.
Bug report
Describe the bug
Supabase allows one originator to be supplied via the dashboard, but does not allow override of that originator when using the phone auth APIs. I've registered multiple originators with the same name and they work fine, but I can't add support for US phone numbers because it requires that I use a separate virtual phone number for compliance with 10DLC regulations. Any SMS to US phone numbers fails as it tries to use the default originator supplied in the dashboard.
To Reproduce
Steps to reproduce the behavior, please provide code snippets or a repository:
Expected behavior
Devs should be able to override the originator. I think adding an optional value to the
verifyOTP
endpoint to allow an override of the default originator when a user enters a phone number from a country with specific requirements would allow devs to handle edge cases like 10DLC regs.Screenshots
If applicable, add screenshots to help explain your problem.
System information
Additional context
I've contacted MessageBird support and they've confirmed that there is no logic for routing calls based on country inside their API, it has to be handled by the dev inside the API call.
The text was updated successfully, but these errors were encountered: