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 < reply@reply.github.com

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: https://github.com/OpenHamilton/hsrsms/issues/2#issuecomment-3117573

-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