An example from the API page for the curious:

Sending an SMS from 415-555-1212 to 555-867-5309 asking Jenny if she wants to get dinner:

  POST /2008-08-01/Accounts/AC309475e5fede1b49e100272a8640f438/SMS/Messages HTTP/1.1
  From=415-555-1212&To=555-867-5309&Body=Hi+Jenny%21+want+to+grab+dinner%3F

http://www.twilio.com/docs/api/2008-08-01/rest/sending-sms

On a scale of one to fucking nuts, this is fucking nuts.

Am I the only one that thinks someone is going to build a killer service on top of Twilio? Something to become a household name and be totally disruptive.

Twilio has by far one of the best APIs out there. Most APIs hands you back data, Twilio does "stuff" so you do not have to.

Who else would you include in this category?

I think i might base my next startup entirely off of using some twilio functions after this price lowering and some research. It's a business app, but it would trickle down to interact with a lot of consumers.

I have been playing around with it for personal use and it has contributed more business ideas to the notebook than anything else I've done. With SMS I'd give better than even odds of one of them being my next business.

yup. the sms is a nice supplement. i really need to dig in deep and think of some use cases.

for the consumer side, i dont know if youve seen this chatroulette thing. might be fun for shits and giggles to do that with twilio. no clue how it could be sustainable though.

Same pricing as Clickatell (http://www.clickatell.com/pricing/message_cost.php) -- which I consider to be an impressive fact.

What I like best about this API is that it sends and receives via a regular phone number that you own as part of your Twilio account. That's waaaaay less complicated -- and way cheaper -- than futzing around with shortcodes and the like (as anyone who has ever investigated shortcodes can attest).

This is hands-down game changing.

I personally can't wait to see what the competition does. I hope Twilio left some wiggle room in their $0.03 price in case they have to go into a pricing war with other providers (thinking Google).

To me this means I have no reason not to TXT enable all of my apps. It also offers a quick and easy way to make money for a lot of "freemium" services out there. Just enable TXT updates and up-charge per TXT (possibly).

Keep in mind that you can only send one message every second. That is a pretty low throttle. If your service were to take off you would probably need to switch to a bigger aggregator.

To be clear, the throttle is 1 message per minute per phone number (which is $1/month), not per account.

-danielle (@twilio)

Really? One per minute per number? That's a pretty big limitation.

Edit: I think Danielle just mistyped. From the FAQ: "Each of your Twilio SMS-enabled phone numbers can send SMS messages at a rate of 1 message per second. You can make requests to Twilio as fast as you like, and Twilio will queue the messages, releasing them at a rate of 1 message per second. It is not possible to adjust this rate."

Eek yes, 1 msg per second per number... I think it's time for me to go to bed.

danielle (@twilio)

Either way, imagine you need to send out 100 messages. That would be 100 seconds (or even worse 100 minutes.) Imagine if you needed to send out 1,000 or a million. Its going to be hard to build a solely SMS service around this based on that limitation. I think this is awesome if you want to add SMS alerts to your existing website or build a proof of concept, but I don't think your going to build an SMS app on top of this API.

Well if your service is sending out 100 messages in one second then you can probably afford the $1-$2/month charge to add more numbers.

Especially since you are already paying $3 per minute for the 100 messages.

http://www.twilio.com/pricing-signup says that it's 3 cents/SMS - which, yes, works out to be $3 - but not because it's per minute.

My point is that you have 86,400 seconds in a day. Well before you are spending $864 per day maxing out the number of messages you can send, you have $1 in the bank to get another number.

But then again, having a bank of 100 phone numbers just to send the million messages you want to send within an hour sounds slightly annoying from a logistics perspective.

The point is: you buy more phone numbers at $1/month to increase your capacity.

Clickatell is now lowering their prices: http://www.clickatell.com/us_price_freeze.php?cid=113216

This looks excellent, although at the moment I can't think of a use aside from notifications (which is awesome either way).

But you NEED to go after sms payments. They're horrendous at the moment and completely unusable for most people because of the high fees. I'm really hoping some startup can tackle it and turn it into a viable payment solution.

You might check out http://venmo.com/ They have a dead simple SMS payments platform.

-evan (@twilio)

I checked it out, and it looks handy (requested an invite, but we'll see how it goes) although perhaps I worded it wrong.

I meant sms billing, services like zaypay/daopay. It's just that now the fees are so horribly high that it's almost pointless.

I wonder how they do send payment sans venmo account. According to their info page it can be done with just a cellphone...

"Previously, building SMS apps was hard... "

Is this true? In the UK at least it's been ridiculously simple and cheap to build SMS apps for years. I've built several and the last I had up and running in an hour from start to finish. What's a little harder (for me anyway) is coming up with ideas for SMS services that are actually useful.

The rest of Twilio's stuff looks awesome though, I wish they'd bring it to the UK!

Yes it's definitely true. Most of the options are very expensive, or not available in Canada (where I live).

Congrats to Twilio! (I'm an investor)

Very cool.

This would be even better with shortcode support.. The FAQ simply says "not available at this time". Does anyone know if there's a time frame for that feature?

I am impressed with what Twilio is doing here. However, if you'd like to send via a short code (no setup fees, delays, etc - using a shared shortcode), you can check out our developer center @ http://www.eztexting.com/developers

We also allow your customers/clients/whoever to interact via keywords on the shared shortcode (313131 in the US / 393939 in Canada)

This is simply groundbreaking. I worked on an SMS project about a year ago that failed because of the difficulty and cost in working with SMS. This API would make it trivially easy, not to mention absurdly cheap. I can't wait to give this a try.

Well, at least here in Finland we have had these sms api services for a while. Not that cheap though.

This is going to pose some competition to TextMarks - which has a very powerful, yet simple API. This works out to be cheaper although you don't get the shortcode like TextMarks has. Glad to see Clickatel is facing some competition.

It mentions 3c per message, is it the same price for international messages as well?

And also if it works internationally ... are there international phone numbers for inbound SMS?

From their FAQ, it says you can send to and receive from international numbers for the same pricing (subject to change in the future). However, you can only send from and receive to a US based local (not toll-free) Twilio number.

Apropos of this, are there any decent sms payment services out there? What about sms payment api's? I know they are pretty popular in europe, but seemingly have not caught on in the states. thoughts?

A race to the bottom in prices. Model might be in trouble when Google gets in the game. Great company, though.

Awesome. Is anyone familiar with MessageMedia's sms software and how it compares to Twilio?

iPhone SMS allows forwarding of SMS messages. Is this a common feature of phones? Of smartphones, or more?

I'm going to have fun writing my contest entry.

Check out [http://www.twilio.com/docs/quickstart/sms/tracking-conversat...]. It says that the session variable is stored as the context between two numbers. Is that a unique pair, or is it a direction pair?

In other words, is the $_SESSION between $_REQUEST['From']=='Zack' && $_REQUEST['To']=='HN' the same as the $_SESSION between $_REQUEST['From']=='HN && $_REQUEST['To']=='Zack?

If that's the case, then the example provided in your documentation is flawed, because you're saying:

A) <Sms><?php echo $name ?> has messaged <?php echo $_REQUEST['To']." ".$counter ?> times</Sms>

When you really mean

B) <Sms><?php echo $name ?> has messaged OR BEEN MESSAGED BY <?php echo $_REQUEST['To']." ".$counter ?> times</Sms>

Hi Zackattack,

It's bi-directional... ie, cookie state for the conversation. But in the quickstart, if you think about it... you only increment the counter once for the received message and the reply that the script is going to send, so the counter works out correctly. You had us thinking for a few minutes there :)

-jeff @twilio

Cool, thanks for getting back to me so quickly.

To clarify, the API/platform supports the following two scenarios:

1) You make an HTTP POST to the SMS resource 2) Twilio automatically sends out a text message, and simultaneously does a GET/POST of your script, and $_REQUEST contains "From", "To", and "Body" keys

AND

1) Your Twilio phone # receives a text message 2) Twilio automatically pings your script, and inside the ping, $_REQUEST contains "From", "To", and "Body" keys. The value of the "To" key is always your Twilio phone number. (Unless you have multiple Twilio #s, I suppose).

Twilio only hits your URL when somebody sends an SMS to your phone number. So in the #1 scenario, if you sent a message via the REST API, Twilio wouldn't hit your URL. If the person replied, then your URL would be hit.