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.

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

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.