SMS-enabling your applications
webtext.com provides a business messaging platform enabling developers and integrators to SMS (and voice)-enable their existing legacy, or new build, applications. This document provides a short description and break-down on the various means at your disposal for getting your application to send and receive messages. For more detailed information, and to discuss your specific set up, please contact us.
In legacy environments, or on systems with limited networking capabilities, SMTP is perhaps the quickest way to SMS-enable applications. Any application capable of sending email should quite readily be in a position to take advantage of SMS. Outbound messages can be sent as email to <number>@webtext.com. Provided relevant security requirements are met, an email sent in this manner will be converted to SMS and delivered to the <number> specified. Account-level settings can be used to control such things as whether or not the subject line is parsed or ignored, and what the maximum length of the payload can be on such a message. Filters can also be applied server-side to remove lengthy disclaimers or email footers that should not be processed.
Account level features can also be accessed via the SMTP channel. It is possible, for example, to address a single outbound email to a group alias rather than a single cellphone/mobile number. This alias refers to a contact group preloaded on the webtext.com platform by the developer/customer.
Delivery Receipts (DLRs) can be sent back to the sending application, also via SMTP. Some form of handling function would be required on the application-side to parse these receipts.
Replies to text messages sent via SMTP can also be routed back to the originating email address, or to another specified email address, for processing.
A variant on the basic SMTP-based service, this channel is used by applications that require the ability to poll for, and retrieve, inbound messages at intervals. An example of an application using this mechanism is Avaya’s Aura Contact Center (R6.2+). Outbound messages are sent via SMTP (authenticated). Inbound messages are placed in a POP3 mail box for retrieval by the application.
The method most commonly used by developers to SMS-enable their new and existing applications is via the HTTP protocol. A REST-based web service allows access to many of the webtext.com platform functions, where a standard HTTP GET or PUT request can be used to transmit one or many text (or voice) messages.
Outbound messages are sent by calling a specific URI, containing parameters relating to the message. The response to this call is a 3-digit return code, indicating whether or not a message has been accepted for delivery. Issues such as malformed destination numbers, missing parameters and authentication errors will result in a message being rejected. Once accepted, the message is processed and sent immediately or (in the case of a deferred delivery request) at a later specified time.
DLRs (receipts) are provided indicating successful or failed delivery of the message. These are generated, in most cases, by the handset, which acknowledges receipt of the message from its local network. This acknowledgement is than passed back through the network as a delivery receipt. Within the webtext.com API call which was used to send the message, the application can provide a URI to which the receipt should be sent. This URI can contain custom parameters to allow the application marry incoming receipts with the relevant out bound message.
All outbound messages and receipt status can also be accessed via the webtext.com outbox, either through the webtext.com website, or programmatically through an enhanced HTTP API call.
Inbound messages/replies can be routed in accordance with a per-account setting, to a specific URL on the client’s server, to an email address, to a cell phone number, to an XMPP address or simply to the webtext,com inbox, for later retrieval by the client/application.
The Short Message Peer to Peer (SMPP) protocol is an open industry standard messaging protocol, and is one of only a few ‘standard’ methods for the transmission and receipt of SMS text messages. An IP-based protocol, it is generally used for high volume applications, where low overhead provides high throughput. Where traffic levels are expected to consistently exceed 4-5 messages per second, and where none of the added functionality provided by the HTTP API is required, the use of SMPP should be considered.
The application needs to connect to the webtext.com SMSC via SMPP v3.4.