Hacker News new | comments | show | ask | jobs | submit login
Telephony, SMS, and MMS APIs (docs.google.com)
122 points by Glibaudio 480 days ago | hide | past | web | 46 comments | favorite

Dev from ClockworkSMS here.

Just want to correct this list, as we definitely do support SSL, and we've just upgraded the certificate: https://www.clockworksms.com/blog/ssl-sha2/

If SSL isn't enough, we can also do VPNs directly to our (only UK based) datacentres.

Feel free to ask questions if you have them. We've got good links to the US and great coverage throughout the rest of the world

I've used both raw devices and 2 or 3 commercial SMS APIs to implement international SMS systems commercialy over the last 10 years: Middle East, Iran, Europe, East Asia, etc. IMHO the best are the ones that let you send raw SMS PDUs, which isn't that hard. If you want to do international SMS, and care about cost, then using non UCS2 encodings is a requirement. Without raw SMS PDU support, you are basically screwed. Swedish 42IT AB[0] was a good one though their capacity for and speed of detection of route failure was definitely not ideal. I've never needed inbound but did set it up with raw devices back in about 2005 and it worked fine. One technique few people use which I think is great is forwarding your service business' phone number to people as an SMS contact when people sign up to your website. This stuff is becoming a lost art.

[0] http://fortytwotele.com/

I wish I had something like this sooner. I decided to go with Plivo for a side-project of mine and while my experience has been pleasant I really miss MMS support. I'm going to take some time going through this list evaluating different MMS providers. Anybody have any experience with a particular company on this list with MMS that they enjoy?

Twilio is an obvious mention. More expensive than Pilvo (I never heard of them and only need SMS for a project of mine so thanks) but I've never had an issue. Twilio also supports carrier lookups, you might be able to leverage that and send emails to '@mms.att.net' and the like.

MMS Providers seem to be few and far between. Looking for an Australian offering at the moment - having some trouble. Any advice welcomed.

I'm actively looking for MMS support, US as well as international.

Twilio does MMS, both inbound and outbound. Pictures only for the US and Canada, though.

Since they're all pretty much the same, the main factor appears to be missing: price.

they don't all disclose price publicly and I'd probably get a takedown notice if I posted prices, b/c they can always change and that's misleading the consumers.

Then add some date/time so that you clearly only claim that at that date/time this was the price.

are you obligated to be accurate? I appreciate the list (thank you, or thank the curator) but I would imagine that if you are independent you have no obligation to be correct?

Not sure.

I see you reposted my post from an internal hackathon hackers post.

It would be good to know which of them support international numbers, or how many country it covers

Seconded. (I am targeting Asia and Africa.)


I wanted to add Mblox to this list, if possible. We provide HTTP, Rest and SMPP connections, along with web based applications. We have over 100 direct operator connections, as well as global coverage to over 978 networks.

We offer MMS support within the US as well as approved US & Carrier SMS connections. I will be more than happy to speak to anyone regarding their requirements - please get in touch, Sarah.Cruttenden@mblox.com

Look forward to hearing from you,

Sarah https://www.mblox.com/

For those of you that don't want to code interactions (going beyond simple notifications) via SMS & especially Telephony/IVR calls - and also let your business team members build and manage these interaction flows via a browser instead, check us out: https://www.engageSPARK.com .

Developers use our Subscription API to trigger an interactive SMS or IVR call campaign (that they've built via our website first) - by simply sending us the campaign ID and the recipient's phone number. This saves them days/weeks of coding to Twilio/Plivo/etc's APIs and they offload all changes to the interaction flows to their business team members. We've been used in 80+ countries, including by Intel and UN WFP. :)

We have an API for sending bulk SMS and libraries written in PHP, NodeJS, Python, Ruby, Java, C#, Go and Rust. You can try out the API and send some test messages to your phone straight from your browser at: https://zensend.io/#demo .

We have the most experience in the UK market because this is where we do most of our premium sms/direct billing business under another company (http://www.fonix.com/) but we support bulk messaging to a lot of different countries (https://zensend.io/pricing).

Oh neat! I hadn't seen this before. Any chance you all would like to get on http://rust-lang.org/friends.html ? :)

The data appears to be culled from ProgrammableWeb.


I had my outsourcer do it. not sure if they scraped it or used LinkKlipper.

Really fascinated of this kind of semi--outsourced work procedure. Outsource the manual data entry to somewhere else for a minimum cost and then focus on your core strengths alone.

I outsource everything I suck at.

So that tends to be a lot of stuff.

Thanks for the list.

I would be really interested in SMS deliverability data by country or region for different SMS API providers. I think it is really key when choosing SMS providers, and it is hard data to get.

Hey dev from MessageBird here. We are "mollie-sms" on the list.

We changed our name long ago and along with the name many other things: We support SMPP, SMPP over TLS, http apis that support TLS (with libs in many languages https://github.com/messagebird), SS7, easy delivery over all over the world (except North Korea).

And many more exciting stuff coming up.

I really wish people would more clearly distinguish library APIs from RPC APIs exposed by corporations' servers. I have no desire to deal with another company but I would love an open-source library implementing the client side of MMS, or at least some readable documentation about how the hell it works.

Do you have example of potential alternative naming schemes?

I would refer to these as "services" and "libraries"; referring to either as an "API" is conflating a tool with its interface.

It would be more useful if the list has inbound/2-way, raw PDU, long/shortcode, sender ID etc.

wow, i'm out of the loop. what is everyone building with these types of APIs?

Two factor authentication and notifications of any type would be the two things that come up in my mind first.

More: allowing contact from offline users (newspapers, tv, radio) and interacting with them, mobile payments.

If anyone is looking for an SMS REST API using a shared short code, check out: https://api.mobiniti.com/v1/docs

I'm currently using Nexmo for a side project, but am looking to move. I recently had to buy some more numbers and realized Nexmo had almost none available. Anyone have this issue with other providers?

Nexmo's inventory especially for North America numbers has been an issue for a while. Are you using them for Voice, SMS, or both?

Just SMS as of now. I'm looking into moving over to something with shortcodes now.

Its a great list but what's the context?

Twilio's IPO just occurred.

Do you expect worse service because of the ipo?

I've done this before and HATED it. Outside the usa is a nightmare. I mostly used clickatell and tropo

Would be nice if it included pricing per # and per SMS msg sent, etc...and any other fees.

none of these companies will list their prices publicly... twilio will b/c they're probably slightly over priced.

Always negotiate lower prices and shop around.

Plivo, Nexmo & Bandwidth all list their (much lower) pricing.

Here are the pricing pages for two services that I looked into as possible alternatives to Twilio:



I use both of these services and Flowroute https://www.flowroute.com/pricing/pricing-sms/- Flowroute's pricing is really competitive.

Nexmo has great analytics that show failures. Plivo will just fail and not log it and not return a failure, so I'm migrating away from them.

Thanks for putting this list together!

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact