Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle multiple originators for MessageBird phone auth #1572

Open
2 tasks done
danbeech opened this issue May 6, 2024 · 2 comments
Open
2 tasks done

Handle multiple originators for MessageBird phone auth #1572

danbeech opened this issue May 6, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@danbeech
Copy link

danbeech commented May 6, 2024

Bug report

  • I confirm this is a bug with Supabase, not with my own application.
  • I confirm I have searched the Docs, GitHub Discussions, and Discord.

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:

  1. Setup your project using MessageBird for phone OTP
  2. Register originators for countries that allow it, e.g. UK, most of the EU
  3. Register a US number with 10DLC
  4. 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.

@danbeech danbeech added the bug Something isn't working label May 6, 2024
@J0
Copy link
Contributor

J0 commented May 7, 2024

Hey @danbeech,

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

Let me know

@danbeech
Copy link
Author

danbeech commented May 7, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants