`signInWithOtp()` not working with Twillio if we provide an `Service Sid` instead of phone number.

[hasanmhallak]

Bug report

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

Describe the bug

It appears that providing a Twilio Message Service Sid instead of a phone number as shown in the docs here will throw an exception from twillio itself. but I think the problem is from gotrue side not Twillio duo to the fact that it working normally when try it using cURL like this:

curl 'https://verify.twilio.com/v2/Services/[Service Sid]/Verifications' -X POST \
--data-urlencode 'To=+XXXXXXXXX' \
--data-urlencode 'Channel=sms' \
-u [Account Sid]:[Auth Token]

Error

AuthException(message: Error sending confirmation sms: The 'From' number [Service Sid] is not a valid phone number, shortcode, or alphanumeric sender ID. More information: https://www.twilio.com/docs/errors/21212, statusCode: 400)

[azlekov]

Same issue here. +1

[J0]

Hey all,

Thanks for taking the time to file an issue. Quick check - the link below:

curl 'https://verify.twilio.com/v2/Services/[Service Sid]/Verifications' -X POST

looks like a Twilio Verify link - were y'all hoping to use Twilio Verify with Supabase auth?

[hasanmhallak]

hey @J0, I'me not sure what you meant by hoping to use Twilio Verify with Supabase auth but I tried this link to try and check if the Twilio Message Service Sid will work or not as Twillio docs said. And it works fine.

Given the exception I had, I can bet that supabase implementation uses the SID in the From field. Because when putting a number purchased from Twillio like the video in the docs it works fine.

Purchasing a number from twillio will cost a monthly fee to preserve that number, and in this case using the Service Sid is more convenient.

For the record I tried to use the verify api by Vonage and it works fine.

[azlekov]

The SID can be checked if is a messaging or verify SID. Based on that different APIs should be used.

References:

• https://github.com/nhost/hasura-auth/blob/main/src/routes/signin/passwordless/sms/sms.ts#L103-L127
• https://github.com/nhost/hasura-auth/blob/main/src/utils/twilio.ts#L5

[J0]

Hey @hasanmhallak,

Apologies, I re-read the message and realized that it could be potentially be interpreted as curt and even offensive. That was not my intention and I apologize if it came across that way.

For context, we have a similar but separate provider, Twilio Verify, which is currently feature flagged and due to go out shortly. To make use of Twilio Verify we'd need to enable a flag on the project to allow the use of the feature. The flag would toggle signInWithOtp to use a separate API endpoint specific to Verify SIDs. We'd previously release and retracted the documentation so wanted to check if y'all were part of the set of users who had seen the documentation and were trying to use the feature. I could have explained myself better - sorry about that.

Let me confirm that the endpoint is working with a Message Service ID and I'll also check if we're ready to unflag the Twilio Verify endpoint shortly after.

[hasanmhallak]

no need to be, really. I did't take it as an offensive or anything, it's just I thought maybe I'm using this feature in the wrong way, cause you know there is a message and a verify api.

I indeed use signInWithOtp and here is the code from the client side written in dart.

 Future<Either<Failure, String>> createAccoutWithPhone(
    String phoneNumber,
  ) async {
    try {
      await Supabase.instance.client.auth.signInWithOtp(
        phone: phoneNumber,
      );
      return right(phoneNumber);
    } on AuthException catch (e) {
      print(e);
      late int code;
      if (e.statusCode == '422') {
        code = ErrorType.invalidPhoneNumber.errorCode;
      } else {
        code = ErrorType.unknownErrorCodeFromServer.errorCode;
      }
      return left(
        Failure.server(
          code: code,
          message: e.message,
          stackTrace: StackTrace.current,
        ),
      );
    }
  }

When I switched to use Vonage I also used this verify api and it works fine:

curl -X GET "https://api.nexmo.com/verify/json

Hope this might be more useful to you.

[J0]

Hey all,

Thanks for your patience. Going to close this issue since we've since rolled out Twilio Verify and it should be possible to use the Twilio Verify provider with a Verification Service ID now. Do let us know if there are any further issues using Twilio with a Message Service ID or Twilio Verify with a Verification Service ID and we'll re-open issue.

Thanks everyone!