
Introducing Our Ridiculously Simple Twilio SMS API - johns
http://blog.twilio.com/2010/02/introducing-a-new-api-twilio-sms.html
======
mrduncan
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>

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

------
djb_hackernews
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.

~~~
rokhayakebe
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.

~~~
tectonic
Who else would you include in this category?

------
jsdalton
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).

------
dpcan
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).

------
matthewer
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.

~~~
danielle17
To be clear, the throttle is 1 message per minute per _phone number_ (which is
$1/month), not per account.

-danielle (@twilio)

~~~
johns
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."

~~~
matthewer
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.

~~~
Vindexus
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.

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

~~~
oconnor0
<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.

~~~
gridspy
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.

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

------
decadentcactus
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.

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

-evan (@twilio)

~~~
decadentcactus
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.

------
almost
"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!

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

------
joshu
Congrats to Twilio! (I'm an investor)

------
bhousel
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?

~~~
jsm386
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)

------
fuzzmeister
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.

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

------
eapen
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.

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

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

~~~
scotje
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.

------
d4ft
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?

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

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

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

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

Check out [[http://www.twilio.com/docs/quickstart/sms/tracking-
conversat...](http://www.twilio.com/docs/quickstart/sms/tracking-
conversations)]. 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>

~~~
jeffiel
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

~~~
zackattack
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).

~~~
jeffiel
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.

