Outbound Apps – How They Work in Scripting vs WebAPI

May 23rd, 2012 by Justin Dupree

Sending texts or making calls with Tropo can be a little counter intuitive if you’re accustomed to the pure REST implementations common to SMS APIs – POST the destination phone number and the message content to a specific URL, text goes out, end of story. With Tropo, you need a “launcher” app that handles the REST bits and a “catcher” app that actually sends the text, which adds a bit of complexity but also an immense amount of features.

The first app, the “launcher”, will create a REST request, either a GET or POST, that contains one of your application tokens and any parameters to pass over (such as the number to call). The token is your authentication, so no need for a user/pass or BASIC auth, and they’re found underneath the URLs for the actual Tropo app, a.k.a. the second “catcher” app. You’ll have two options:

Each token corresponds to one of the app URLs, so the Voice URL is linked to the Voice token, Messaging to Messaging. If your app has the same URL for both, either token will work fine.

The launcher app can be a plain URL dropped in a browser, like this:

https://api.tropo.com/1.0/sessions?action=create&token=TOKEN&numbertodial=14075551212&msg=test+Tropo+message

which is essentially a GET, or it can be a fully realized app using various languages and REST clients, like curl for PHP:

<?php
$token = 'TOKEN';
$numbertodial = '14075551212';
$msg = 'test+Tropo+message';

$curl_handle = curl_init();
curl_setopt($curl_handle,CURLOPT_URL,'http://api.tropo.com/1.0/sessions?action=create&token='.$token.'&numbertodial='.$numbertodial.'&msg='.$msg);
curl_setopt($curl_handle,CURLOPT_CONNECTTIMEOUT,2);
curl_exec($curl_handle);
curl_close($curl_handle);

?>

That app uses POST, though you could use a GET with the app just as easily. The launcher app would reside on your server, tied to be triggered by some criteria, potentially when someone clicks a button on a webpage.

Note that the message needs to have all spaces encoded, which is why the + sign is shown. You can also use:

curl_setopt($curl_handle,CURLOPT_URL,'http://api.tropo.com/1.0/sessions?action=create&token='.$token.'&numbertodial='.$numbertodial.'&msg='.urlencode($msg));

Ruby has a library called net/http that would work, Python has the urllib and urllib2 libraries, whatever you want to use would be fine as long as it can send a GET or a POST.

Your second app would look like the apps in one of these examples:

Scripting:

https://www.tropo.com/docs/scripting/passing_in_parameters_voice.htm

https://www.tropo.com/docs/scripting/passing_in_parameters_text.htm

WebAPI:

https://www.tropo.com/docs/webapi/passing_in_parameters_voice.htm

https://www.tropo.com/docs/webapi/passing_in_parameters_text.htm

The first set of examples are for apps created for the Scripting API – a Scripting app uses a script hosted on our servers (conveniently called “Hosted File” when creating a Scripting app); your launcher app would trigger it to run using the token, and everything else happens on our side. The sequence of events would look like this, if your launcher app was tied to a webpage:

  1. User loads your webpage, clicks a “send text” button or something similar
  2. Your serverside launcher app is triggered and sends the REST request to our servers
  3. Your Tropo app launches and sends the text message

The second set of examples is an app using the WebAPI; this API communicates with an app that’s actually running on your server, but sends instructions to our servers using back and forth JSON. This sequence of events for this one would look like this:

  1. User loads your webpage, clicks a “send text” button or something similar
  2. Your launcher app is triggered and sends the REST request to our servers
  3. The Tropo app launches and sends session JSON to your catcher app, also hosted on your server, asking for instructions
  4. Your second app replies with JSON that tells Tropo to send the text message
  5. Tropo sends the text message

Many developers using the WebAPI get stuck at this spot – it seems overly complex, and for a very basic SMS app that’s a legitimate thought. If all you want to do is send plain texts without any need to process responses, capture input, anything except deliver the text, then the Scripting option is often easier. Copy one of the examples from the docs, add a Scripting app and then build the launcher app in whatever language you want.

Hope that helps clarify the different processes; as always, if you get stuck, please don’t hesitate to post in our forums and ask for help.

Related posts:

  1. Sending outbound SMS with Java
  2. WebAPI: Now with outbound and transcription
  3. How-To: Sending an SMS using WebAPI
  4. How-To: Sending an outbound SMS from Tropo
  5. New Java based WebApi implementation

Tags:

Leave a Reply

Please note: By submitting a comment you agree to comply with our Comment Policy. We welcome all comments, positive or negative, but do reserve the right to remove all or part of blog comments that do not comply with our policy.

Additionally, the first time you leave a comment on this blog, it will be held for moderation. After that first comment has been approved, future comments will be posted without delay.

Additional comments powered by BackType