Tropo is broken
December 10th, 2011Oh. my. god. What a giant disaster.
I’ve been raving about how awesome Tropo is at handling SMSes to everyone I talk to, but no more. Tropo expects EVERY interaction to be the in the form of a response to a request that they’ve POSTed to your API endpoint.
Everything is part of a session THROUGH THEIR SERVER AND BACK TO YOUR CALLBACK URL. Want to send an SMS? First you need to create a session. Consider the Java library (in Scala):
val result = api.launchSession(token) if (result.getSuccess) { api.message(...) ... } |
All valid, type-safe code. launchSession() returns a TropoLaunchResult, which indicates whether the session was successfully created and, if so, its session id.
We can work with this, right? WRONG! As part of the session creation Tropo will throw a session creation object at your callback URL:
00020 0000 11:22:41 PM ApplicationInstance[http://miogiro.pr1001.cloudbees.net/tropo.json , sas_2-15-sm1778xfp7g8g0dtropo] starts execution on Thread Tropo-Thread-3899e36f1ad7650f2848c3ac12332b96
00021 0000 11:22:41 PM Thread Tropo-Thread-3899e36f1ad7650f2848c3ac12332b96 acquired engine com.tropo.rest.engine.TropoScriptEngine@78ded0e7 of type tropo-web, activeEngines = 4
00022 0000 11:22:41 PM Sending TropoML Payload on Tropo-Thread-3899e36f1ad7650f2848c3ac12332b96 [url=http://miogiro.pr1001.cloudbees.net/tropo.json]: {"session":{"id":"3899e36f1ad7650f2848c3ac12332b96","accountId":"notsharing","timestamp":"2011-12-09T23:22:41.612Z","userType":"NONE","initialText":null,"callId":null,"parameters":{"token":"notsharing","action":"create"}}}
00023 0000 11:22:41 PM Received non-2XX status code on Tropo-Thread-3899e36f1ad7650f2848c3ac12332b96 [url=http://miogiro.pr1001.cloudbees.net/tropo.json, code=500]
00024 0000 11:22:41 PM Thread Tropo-Thread-3899e36f1ad7650f2848c3ac12332b96 returned engine com.tropo.rest.engine.TropoScriptEngine@78ded0e7 of type tropo-web, activeEngines = 3
00025 0000 11:22:41 PM ApplicationInstance[http://miogiro.pr1001.cloudbees.net/tropo.json , sas_2-15-sm1778xfp7g8g0dtropo] ends execution on Thread Tropo-Thread-3899e36f1ad7650f2848c3ac12332b96
00026 0000 11:22:41 PM sas_2-15-sm1778xfp7g8g0dtropo invalidated
00027 0000 11:22:41 PM Instance 3899e36f1ad7650f2848c3ac12332b96 removed
See what’s happening? If you fail to handle it and return a 200 status code (and a Tropo JSON verb?) it kills the session, never mind that I have no need for that. That means it’s literally impossible to send an SMS without a server setup to receive callback messages from Tropo. Oh, and of course you can only specify one URL: you’re supposed to route all the different requests based upon extra parameters you stick in the session creation requests.
It literally boggles the mind how someone could have thought this was a good idea.
Tropo, if you want to fix this and need help send me an email at peter@bubblefoundry.com. Tropo competitors, if you have a sane API to send SMS messages and callbacks to response to received messages (bonus points for a Scala or even Java library) and provide UK numbers that can handle both inbound and outbound SMS, feel free also to email me at peter@bubblefoundry.com.
December 11th, 2011 at 1:56 pm
Interesting.
So… i was wondering why when i sent an SMS to a user and then I also wanted to send an SMS to an ‘admin’ phone number that kept track of things, that ‘admin’ phone number never got the message, in fact the user would get both SMS texts… is that why?
Cause i didn’t have a server setup or anything, it was a test app running from their servers.
December 11th, 2011 at 7:34 pm
I have no idea. You should ask Tropo support or the community on their forums.
December 12th, 2011 at 5:56 pm
Peter, I’d love to talk, and although you already have my email address, I’ll respond to your “if anyone at Tropo wants to talk” batsignal (or is that “Google-Alert-Signal”?) anyway.
Tropo’s API is designed to be conversational. When we built Tropo, there were already tons of simple REST apis that you could use to broadcast SMS. Building yet another API to blast SMS with a curl request, didn’t seem like something the market needed. We’ve long been in the business of automating customer self service (think IVRs), and what WAS missing from the market was IVR-over-sms — the ability for a computer to hold a conversation with a customer via SMS. For this reason, we allow you to things like ask questions, and get the responses back inside the same Tropo session. No need to build your own session tracking and handling. And the same code you use to build a voice IVR works over SMS. See https://github.com/tropo/tropo-samples/blob/master/php/localsearch.php for an example of a multichannel application, all backed by the same bit of code.
To work with Tropo, you write some code that can be hosted on our server, or on your own, through http and json. When a phone call or text comes in, we run that code. That part seems to be normal enough from your perspective, right? When you want to initiate a phone call or send a message, we use that same code. You send us an http request that tells us “hey, Tropo, run my code!” and we hit your callback URL to find out what you want us to do. That’s the part that’s a mind-bender for a lot of web developers, and frankly if all you want to do us blast out an SMS, it’s a little awkward. Two http requests (one from you to us, and one from us back to you) to send one simple message?
The parameters aren’t designed to help you route requests, but to allow you to pass data into your application at runtime. You could use this to set different routes if you want, but most people use it to do things like pass in the phone number they want to dial, the message to send and that sort of thing.
I totally understand that if all you want to do is send out a standalone SMS you just want to
hit a URL and be done with it. That’s why Mark Headd and others suggested using Tropo Scripting. Using that and very little code, you can actually right your own REST interface. Heck, we’ve done that for you if you don’t want to write your own. See https://github.com/tropo/simpleMessage and the blog post describing it at http://blog.tropo.com/2010/11/19/simple-post-and-get-interface-to-tropo-sms/
Shoot me an email directly if you want to talk more about this: adam@tropo.com or if you’d like, I’m happy to have a phone call with you about it.
–
Adam Kalsey
Tropo Product Manager
December 12th, 2011 at 6:05 pm
Aysar,
If you do a “say” into a session, by default, that say will go to the first “call” in the session.
As an example…
call(’1234′);
say(‘This goes to 1234′);
call(’5678′);
say(‘This also goes to 5678′);
The “active” call is the one to 1234, so everything goes to that. You can do things to direct the say at specific instances of the call, but in the case of just sending a message, we’ve created a shortcut that does it for you. It’s a Tropo verb called “message” and is available from either the hosted Scripting environment or the json-over-http WebAPI.
See https://www.tropo.com/docs/scripting/mixing_text_voice.htm (that doc talks about having a voice and a text call in the same app, but applies to two text or two voice calls, too.
January 5th, 2012 at 6:30 pm
Couldn’t agree with you more Peter. The API is a total nightmare to work with.
September 22nd, 2012 at 3:16 am
The object model for Tropo’s JSON & REST API is seriously screwed up. As a result the API wrappers written in PHP, Ruby, Javascript are messed up too. We’ve built third-party-call control using Twilio and Tropo. Twilio was a breeze. Tropo is a nightmare. There’s absolutely no software engineering design. Seems like a bunch of incompetent people working on Tropo.
September 22nd, 2012 at 6:59 pm
Much as the Tropo API has frustrated me in the past, the people there are definitely not incompetent. I think it’s more an issue of a conceptual mismatch: people like me assume a stateless web-style request-response API, while the entire API is designed around a stateful telephone call session concept.
November 25th, 2012 at 7:39 pm
What do you think of http://www.smsified.com in closed beta and http://www.OneAPI4SMS.com that is open for business.
November 25th, 2012 at 10:22 pm
SMSified (which happens to be by the same people as Tropo) looks really nice but is only for the US. I’ve never heard of OneAPI4SMS until now.