[Twilio Auth Provider] otp codes are not sent or sent with huge delay

[iosephmagno]

Bug report OTP codes sent via SMS dont arrive to some numbers. At same time OTP codes arrive if we send them outside Supabase, from Twilio via Curl.

curl -X POST "https://verify.twilio.com/v2/Services/[OurTwilioVerifySID]/Verifications" --data-urlencode "To=+447467285767" --data-urlencode "Channel=sms" -u OurTwilioAccountSID:OurTwilioAuthToken

To reproduce You can send otp codes to this number via both Gotrue and Twilio curl. https://receive-smss.com/sms/447467285767/

Logs will report an error returned by auth.signIn final response = await auth.signIn(phone: phone);

Other related issue We happen to receive some otp codes, from previous unsuccessful requests, all at once after more than 30min. Maybe there is also a traffic issue on Gotrue server?

Our Twilio Settings Our Supabse Setting page for Twilio is configured properly. This page made us also think that a potential reason of this issue might be that Twilio asks us to enter Message SID, but we use Verify SID in a Twilio curl request. We would expect to enter Verify SID in Supabase console as well.

Please notice we temporarily switched to MessageBird in order to workaround this issue. But Twilio settings should be filled in.

System information Version of supabase-flutter: 1.2.2

[hf]

@iosephmagno from the looks of it, it appears you are referencing Verify SID which is part of the Twilio Verify API. At this time GoTrue / Supabase Auth does not support Twilio Verify. A number of users have asked for this, but we don't have a timeline on it just yet.

Note that SMS deliverability depends solely on Twilio. Please send us some logs or a reproducible example if the GoTrue code is crashing or logging an error.

[iosephmagno]

@iosephmagno from the looks of it, it appears you are referencing Verify SID which is part of the Twilio Verify API. At this time GoTrue / Supabase Auth does not support Twilio Verify. A number of users have asked for this, but we don't have a timeline on it just yet.

@hf thanks for looking into this.

Yes, sending otp codes with Twilio is done via Verify. It is their service for Auth and they also price it differently from Message. I might be wrong, but sending otp codes via Message might cause problems in some edge cases. If you guys could make some time for it, switching code to Verify api shouldn't be difficult (different endpoints but similar fields).

Note that SMS deliverability depends solely on Twilio. Please send us some logs or a reproducible example if the GoTrue code is crashing or logging an error.

Tried to inspect Supabase logs but we get this error. We opened an internal ticket for that.

[kangmingtay]

Hi @iosephmagno, the Twilio integration we built is solely for messaging purposes and we verify the OTP in gotrue when you call supabase.auth.verifyOtp(). Twilio Verify handles the verification of the OTP code on their end which we don't plan on supporting for now.

[iosephmagno]

Hello @kangmingtay. We still cannot read supabase logs (opened a ticket for this), but at first glance, something doesn't work as expected.

For example, we made this test using the same phone number: 1) ✅ we do receive OTP code with MessageBird 2) ❌ we don’t receive OTP code with Twilio 3) ✅ we do receive OTP code with Twilio curl using both Verify and Message endpoints outside Supabase (tested on same numbers used in point 1 and 2)

This combination of facts make us think that it should be a Supabase's issue with OTP verification.

I already provided this number where you should be able to reproduce the test described above https://receive-smss.com/sms/447467285767/

Please double-check things on your side. We will tell you more as soon as we can read logs from supabase console. Thx

[iosephmagno]

@kangmingtay just to confirm we have no logs issue. Another thing done and integrated to above comment is to check that we can send otp with Twilio with both Verify and Message endpoints. We wanted to test also with Message service since it is the one you are using in gotrue.

[iosephmagno]

@kangmingtay closing this because it seems it was twilio issue. Thanks for the kind support 👍