Here's what's happening, as I see it (corrections welcome):
1) Spammer sends spam to customer's Twilio number.
2) Customer has this number set up to forward incoming texts to employees.
3) Customer has no available API to detect whether texts are spam.
4) Twilio apparently can detect that this message is spam, but rather than simply dropping it at step 1, they're blaming the customer.
Sorry, there is no scenario under which this is the customer's fault.
If you have a business that deals with spam texts or if you host a honeypot for whatever reason you are allowed to do it. You are allowed to receive spam and do whatever you want with it except sending spam over twilio itself because it's against their ToS and to protect their own core business from getting their numbers blacklisted.
if twilio can not differentiate between inbound messages that are being forwarded and outbound messages that are created by the twilio customer then their service can't guarantee to be reliable because someone could basically create a DOS attack by sending spam to any twilio customer expecting that twilio will blame their customer and suspend the account.
It's not their job to differentiate they are just a carrier they scan for outgoing spam to protect their own core business and to not get blacklisted everywhere. Read the ToS they are pretty specific about it.
but then they are simply not suitable for the use case of forwarding inbound messages because the risk is to great that i'll get shut down just because i am receiving spam.
They're receiving the spam because it's sent to the customer.
They're sending spam when the customer asks.
They're also deciding that that customer is a customer no longer because of the choices that customer made with regards to sending spam, not receiving spam.
...or the complaints that caused the account suspension didn't come from Twilio. More than likely, the employee cell carrier noticed the spam and sent an automated complaint to Twilio, and then Twilio acted.
That doesn't excuse poor support, and the lack of resolution, but it changes a lot of the assumed processes.
1) Spammer sends spam to customer's Twilio number. 2) Customer has this number set up to forward incoming texts to employees. 3) Customer has no available API to detect whether texts are spam. 4) Twilio apparently can detect that this message is spam, but rather than simply dropping it at step 1, they're blaming the customer.
Sorry, there is no scenario under which this is the customer's fault.