Review of mass SMS providers.

[oreillyj]

The project should be generating the responses we had discussed on the RHOK weekend shortly. I have begun to review some of the possible mass texting solutions available. Some sites provide mass texting services for free but prepend some kind of advertisement.
Here are some providers:

EzTexting
Website - http://www.eztexting.com/group-sms-pricing-ca.html
API - http://www.eztexting.com/developers/rest-api/sms/code-examples/python.html
Notes - I'm assuming we will need 'express texting' as it needs to be quickly transmitted

CardBoardFish
Website - http://www.cardboardfish.com/sms/Canada.html
API - includes Python API
Notes - I do no see the Bell network in the coverage section, though Rogers is there. There is a setup fee of 50 EURO and you must rent a virtual number for 75 EURO per annum. Appears to be the cheapest per message if sending >50k texts per month.

BulkSMS
Website - http://www.bulksms.com/int/coverage/country/166
API - HTTP (easy to implement in Python)
Notes - Appears to have solid coverage and implement a pay as you go pricing.

And may more...
Any thoughts?

[Incognito]

If we move towards any specific API, is it trivial to change to another at a later date?

[TheCycoONE]

As I said, I have some technical experience (but no financial involvement) with CellTrust

so
CellTrust
Website - http://www.celltrust.com
API - HTTP, SOAP, and Java
Notes - World wide, high availability. I know they have per SMS pricing that varies by country; I'm not sure about the annual fee.

[oreillyj]

@0xdeadcafe
Which ever provider we choose we should ensure it scales to meet our demands both financially and technically to prevent the possibility of a service interruption.

For testing purposes there are free trials available with some providers.

[Incognito]

@Jasindros Of course, our primary goal is in choosing a provider for our own implementation, but I'm asking "what if" we deploy this in another city, where we are not the maintainers? Thus, the abstraction layer that can deal with different APIs may be a nice feature, but not something that needs to be our primary goal.

I have no experience with any of these SMS gateways, so I can't comment on them. Perhaps we could contact their sales department and explain what we're intending to do, as they may see long-term profits if they give us a free one.

[justinkwanlee]

@TheCycoONE Would you be able to find out how much they price from your company that you work with?

[oreillyj]

@0xdeadcafe
This is a good feature that will need to be included for robustness. I can see potential for this project in underdeveloped countries. Hamilton is only the beginning. For other RapidSMS developers it would be more beneficial if the abstraction layer were built into RapidSMS itself.

[Incognito]

I entirely agree, just curious if the layer existed somewhere, if not, lets
maintain this course and deal with it down the road.

On Mon, Dec 12, 2011 at 8:50 PM, Jasindros <
[email protected]

wrote:

@0xdeadcafe
This is a good feature that will need to be included for robustness. I can
see potential for this project in underdeveloped countries. Hamilton is
only the beginning. For other RapidSMS developers it would be more
beneficial if the abstraction layer were built into RapidSMS itself.

---

Reply to this email directly or view it on GitHub:
#2 (comment)

-Brian G.

[JoeyColeman]

Weird, I thought I commented on this issue last week.

I'm talking with Tropo and looking into twilio which expanded into Canada.

[oreillyj]

Someone has built a library for twilio-powered apps in Django found here:
https://github.com/rdegges/django-twilio