[ChrisDutrow]

Ok so are you saying that Twilio cannot be used to rely messages from company phone numbers to employee cells phones?

I would understand if this was an edge case, but my understanding is this is a quite common and a core use case. I'm pretty sure this exact use case is in their basic tutorial.

[FateOfNations]

All the recipient's carrier knows is they see a spam or phishing message originating from Twilio, and (profess to) have a zero tolerance for spam/phishing. They have no idea about context of the "forward to consenting employee" use case or any way of validating it.

If there is any possibility that those messages could be interpreted as spam, that doesn't seem to be a valid use case for Twilio (any more). You could forward the message over some channel other than SMS to the employee (like email, or a custom solution).

[ChrisDutrow]

I think you are right that it's not a valid use case anymore, even if they still assert that it is, because the reality is that it caused this problem. Even if they had responded to me immediately, my phones would have been shut down overnight.

Also, I was looking into the pricing a few months ago and its kind of expensive because I'm actually paying for two text messages: One for the incoming one, and one for the forwarded one.

The code has been working this way since maybe 2015, possibly before (its been so long, I can't remember). I've been using Twilio since I think 2010. I started out just doing call forwarding and later on added text messaging when customers started to expect to be able to text message us.

At the time, it was a core use case. There was a tutorial and everything "Forward text messages to your phone in a few lines of code".