Not working with Verizon

[whitesandybeach]

Okay, I'm certainly grateful for the work that's been done on Textbelt. But it's starting to get a little frustrating, the lack of troubleshooting and visibility into any backend issues.

I've sent three texts today to my 612- number all getting "success":true, and none of them have reached my Verizon phone. One was an alert that one of my servers was overheating, and it appears as if there were a couple more alerts in the last few days that didn't make it either.

How are we sure that Verizon is supported like it says in the documentation? Is there any verification that's done to ensure delivery? Is there any kind of troubleshooting that can be done so i can go to Verizon and say "Hey, what's this issue you have preventing me from getting critical texts?"

I can't use textbelt any more for my server alerts, I could have lost something expensive and I would have been totally unaware.

[typpo]

All good points.

It looks like Verizon blocked Textbelt again. I could switch the server and see if that helps (it usually does). But this is not a permanent solution.

Basically, the more people who use Textbelt, the quicker it gets blocked by providers -- they don't like us using their email-to-SMS gateways in an automated fashion.

We seem to have reached a point where Textbelt is so popular that it's become fairly consistently blocked by providers. For this reason, I don't recommend the free version of Textbelt for mission-critical applications.

To answer your questions,

1) Verizon is supported because we email @vtext.com. This capability is documented by Verizon here.

2) There's no way to ensure delivery without paying money, and this is a free service. success indicates that we've sent an email to your provider's email-to-SMS gateway. Verizon decides what to do with that email.

3) Verizon is probably actively dropping messages from textbelt.com (and other textbelt servers). I suspect this is intentional/perhaps automated by their mail server, and contacting customer service.

If you'd like more transparency, one option is to self-host Textbelt from source. Your server would not blocked by providers because you won't be sending nearly as many texts as I am. As the number of problems with providers increases, this might soon be the only viable option. It is tempting to remove the free Textbelt.com API and force everyone to self-host, but this would still be a disappointment to some.

Option number two is that I can start charging a few bucks for Textbelt and guarantee delivery in the U.S. and eventually other countries, either by mapping phone numbers to a single provider email gateway or by using real telephony software. Obviously I would like to avoid charging because the whole reason I created this project was to enable free outgoing SMS. At this point I don't see other options that would enable me to host a free, reliable SMS API.

[daluu]

@typpo I think one (shorter term) option to make the free service more reliable is to force or default the (free) service to require specifying recipient's carrier. And make that the default (and recommended) documented API mentioned on the docs and website, with alternate one also documented and available for use. As incentive to use the provide carrier version, you could default rate limiting to be stricter for the current API, and be more gracious in limits with the one that requires specifying carrier. And/or require tokens for the current API that doesn't require specifying carrier (you mention you do that for users who exceed the limits).

With specifying carrier, you could at least target the message delivery to particular carriers rather than mass send across carriers resulting in less categorization of textbelt as spam/abuse as its popularity rises.

There's another free SMS API that takes that route, and I've never had problems with delivery with them. Although I can't say they are more reliable than Textbelt. Their ownly caveat is use of CAPTCHA rather than IP rate limiting, making less useful for non-GUI use of their API. http://www.watacrackaz.com/autosms/api.php

[typpo]

This weekend I made the decision to turn down free service on Textbelt.com. There is now an option to pay a small amount for an API key. The paid version reliably texts all carriers within the U.S. The free, open-source version in this Github repository is still available for people to self-host.

I'm closing this issue because it applies to the old Textbelt.com, which was continually abused and therefore blocked by many cell providers. If you are able to reproduce this issue after self-hosting, please re-open it. Thank you!