wireless solutions for a wired world

Sending an SMS using HTTP

Overview

The MX Telecom SMS Gateway allows SMS messages to be sent using HTTP. This page details the format of the HTTP requests which can be made to the MX Telecom SMS Gateway.

Contents

For details on sending other, less-common message types, please click here.

Sending an SMS Text Message using HTTP GET

The MX Telecom SMS Gateway exposes an HTTP interface allowing applications with internet connectivity to send SMS text messages.

A request for a page using the structure shown below is all that is needed for you to send an SMS through the SMS Gateway. The endpoints for these HTTP requests are http://sms.mxtelecom.com/SMSSend for HTTP and https://sms.mxtelecom.com/SMSSend for HTTPS (SSL).

Messages should be sent as a HTTP GET or POST request using the parameters listed below. One request should be sent per message.

HTTP/1.1 is enabled so, if sending multiple packets, the TCP/IP connection should be kept open between requests. If sending message with a high transmission rate is required, then several persistent HTTP/1.1 connections should be used concurrently (perhaps 3 or 4). Pipelining requests, as in Mozilla, is supported but encouraged only where necessary (i.e. with high message rates and large latency between service provider and MX Telecom).

Parameters for all messages

Several parameters are common to all message types, and should be included in the HTTP request regardless of the specific method being invoked. Details of these parameters are as follows:

NameDescription
userUsername of the account to send through
passPassword
smstoMSISDN of the message recipient (eg 447700900999). No leading "+" is required
*smsfromOriginator for the message (ignored for accounts where changing the originator is not possible). Where valid this can be numeric (maximum 16 digits) or alphanumeric (maximum 11 digits)
*noteNote that will be stored in the billing record (maximum 160 characters)
*subaccountSub account that will be stored in the billing record (maximum 10 characters)
*reportFlags for delivery reports (These are bit fields, ie report=7 enabled all reports - default=0):
Bit 1 - Enable intermediate delivery reports
Bit 2 - Enable success delivery reports
Bit 3 - Enable failure delivery reports
*vpValidity period for the message, in seconds
*mxbillingsingleshotEnable single-shot billing for the message. By default, messages are submitted as normal; any non-empty value will enable single-shot billing
(Optional parameters are indicated by a *)

The following example shows the common structure of all HTTP requests understood by the MX Telecom SMS Gateway:

http://sms.mxtelecom.com/SMSSend?user=myusername&pass=mypassword&smsfrom=1234&smsto=447700900999&...

Along with these parameters, there are a variety of other parameters which are needed for the message body, depending on your preference for the encoding/content of the message.

Parsing responses to requests

The gateway's response to all requests uses the HTTP response code to indicate whether or not the request was accepted:

Response CodeDescription
200The request was accepted. The body of the will contain one or more message IDs.
40xThe request was rejected. The possible reasons for this are outlined below. The request should not be retried.
50xThere was a server error. The request should be retried later.

The possible reasons for requests being rejected, along with their corresponding HTTP request codes, are:

ProblemResponse CodeResponse body
Invalid request - eg parameters missing/invalid 400 Bad Request Description of problem, eg Required parameter user missing
Unknown username/password 403 Forbidden Bad username/password
Request not from whitelisted IP address 403 Forbidden You are not authorized to send messages from that IP address
Monthly per-account credit limit exceeded 403 Forbidden Credit limit exceeeded
Daily per-msisdn limit exceeded 403 Forbidden Maximum messages to this MSISDN exceeded
MSISDN not on allowed-reverse-billing whitelist 403 Forbidden Reverse billing Forbidden for <msisdn>
MSISDN on block list 403 Forbidden Destination is blacklisted

Plain text messages

The HTTP request should include the common parameters described above, in addition to the following plain-text-specific parameters:

ParameterDescription
smsmsgThe message text, encoded in the Modified Latin-9 character set (see below).
*flash0 - No flash (Default)
1 - Flash
*split 0 - Don't split long messages. Messages > 160 characters will be rejected. (Default)
1 - Split messages using "..." (Maximum of 5 messages once split)
2 - SMS Concatenation (w. UDH header) - not supported by all phones (Maximum of 4 messages once split)
3 - Split messages into multiple 160 character messages (Maximum of 5 messages once split)
(Optional parameters are indicated by a *)

The example below shows a typical HTTP request for a message of this sort:

http://sms.mxtelecom.com/SMSSend?user=myusername&pass=mypassword&smsfrom=1234&smsto=447700900999&smsmsg=Hello%20World

A form for this message type can be found here.

Or to send a flash message:

http://sms.mxtelecom.com/SMSSend?user=myusername&pass=mypassword&smsto=447700900999&smsfrom=flash&smsmsg=Flashy%20Message&report=7&flash=1

An example HTML form for this message type can be found here.

This will send a message from the account of user username, with password mypassword, to recipient number 447700900999, with the originator of the message set to 1234 (this may not always be possible). The message, in this case Hello World must be suitably URL encoded (eg the %20 rather than a space).

Along with these parameters, there are a variety of other parameters which are needed for the message body, depending on your preference for the encoding/content of the message.

Modified Latin-9 Character Set

Messages you submit in modified Latin-9 or GSM 03.38 character sets are sent on by MX Telecom in a character set appropriate to the destination handset. These character sets normally have fewer characters than modified Latin-9 so some characters in the modified Latin-9 set do not have a direct counterpart. In these instances, our system performs a best-guess mapping, for example turning the character ï into i.

You may also submit messages in UCS-2 Unicode which supports a much wider variety of characters than either the modified Latin-9 set or the GSM 03.38 set. MX Telecom sends these messages in UCS-2 Unicode encoding. However, as UCS-2 Unicode is a 16-bit encoding, using it to send SMS messages restricts the maximum number of characters per message to 70.

See our Knowledge Base for more information about the Modified Latin-9 Character Set and the GSM 03.38 Character Set.

GSM character set messages

ParameterDescription
smsia5The message text, encoded in the GSM 03.38 character set
*flash
0 - No flash (Default)
1 - Flash
*split 0 - Don't split long messages. Messages > 160 characters will be rejected. (Default)
1 - Not yet implemented: Split messages using "..." etc.
2 - SMS Concatenation (w. UDH header) - not supported by all phones
*smsudhOptional hex encoded User Data Header (can only be used when split=0)
(Optional parameters are indicated by a *)

Unicode (UCS-2) messages

ParameterDescription
smsucs2The message text as hex encoded UCS-2
*flash
0 - No flash (Default)
1 - Flash
*split 0 - Don't split long messages. Messages > 70 unicode characters will be rejected. (Default)
1 - Not yet implemented: Split messages using "..." etc.
2 - SMS Concatenation (w. UDH header) - not supported by all phones
*smsudhOptional hex encoded User Data Header (can only be used when split=0)
(Optional parameters are indicated by a *)

The message content should be sent using a series of UCS-2 16-bit words. For example, the character 三 (the Japenese symbol for the number three) is hex-encoded as 4E09. The example below shows a typical HTTP request for a message of this sort:

http://sms.mxtelecom.com/SMSSend?user=myusername&pass=mypassword&smsfrom=1234&smsto=447700900999&smsucs2=03b303b503b903b10021

This will send a message to 447700900999 with the text “γεια!”.

vCard entry

ParameterDescription
vcard_dataThe vcard to send

The example below shows a typical HTTP request for a message of this sort:

http://sms.mxtelecom.com/SMSSend?user=myusername&pass=mypassword&smsto=447700900999&smsfrom=vCardSender&subaccount=&note=&vcard_data=BEGIN%3AVCARD%0D%0AVERSION%3A2.1%0D%0AFN%3AJohn+Smith%0D%0ATEL%3BWORK%3BVOICE%3A442071231234%0D%0ATEL%3BMOBILE%3BVOICE%3A447700900999%0D%0ATEL%3BHOME%3BFAX%3A442071231235%0D%0AEND%3AVCARD

An example HTML form for this message type can be found here.

vCalendar entry

ParameterDescription
vcalendar_descriptionDescription for the event
vcalendar_date_startStart time
vcalendar_date_endEnd time
vcalendar_audio_alarmAlarm time

Time format: yyyyMMddThhmmss y=year, M=month, d=day, h=hour m=minute, s=sec.

The example below shows a typical HTTP request for a message of this sort:

http://sms.mxtelecom.com/SMSSend?user=myusername&pass=mypassword&smsto=447700900999&smsfrom=myDiary&vcalendar_description=Test+Appointment&vcalendar_date_start=20001110T113000&vcalendar_date_end=20001110T120000&vcalendar_audio_alarm=20001110T110500

An example HTML form for this message type can be found here.

SMS with UDH

ParameterDescription
smsudhUser data header. Encoded into hex
*bitsDescribes the content of the message body:
7 - 7bit text (eg EMS messages)
8 - 8bit data (eg Nokia SmartMessaging) (Default)
16 - 16bit data (e.g. UCS-2 messages)
smsmsgBody of the message
If bits=8 or 16:
 This parameter is mandatory
 8 bit message data. Encoded into hex
If bits=7:
 This parameter is optional
 The text of the message (ISO-8859-1)
(Optional parameters are indicated by a *)

An example HTML form for this message type can be found here.

Data messages without UDH

ParameterDescription
bitsDescribes the content of the message body:
8 - 8bit data (eg Nokia SmartMessaging) (Default)
smsmsgBody of the message encoded into hex
(Optional parameters are indicated by a *)

WAP Push Service Indication

ParameterDescription
pushtype0 - Type of WAP Push
push_hrefThis attribute specifies the URI that is used to access the service. If href is empty, or omitted, the SI corresponds to a notification (no service can be initiated).
push_action This attribute may contain a text string specifying the action to be taken when the SI is received.
  • 0 - signal-none
  • 1 - signal-low : The SI MUST be postponed without user intervention.
  • 2 - signal-medium : The SI MUST be presented as soon as the implementation allows that to be carried out in a non-user-intrusive manner.
  • 3 - signal-high : The SI MUST be presented as soon as the implementation allows that to be carried out in a non-user-intrusive manner, or earlier if considered appropriate (which MAY result in a user-intrusive behaviour). This decision can either be based on user preference settings or be carried out at the discretion of the implementation.
  • 4 - signal-delete : If the received SI's action attribute equals "delete", both the received SI and any other (if any) SI with identical si-id MUST be deleted. An SI with the action attribute set to "delete" MUST have an explicitly assigned value for si-id.
*push_siidThis attribute may provide the SI with an identity in order to make it possible to distinguish between different SIs. If this attribute is not specified, its value is considered to be the same as the value of the href attribute. In order avoid conflicts between SIs, it is RECOMMENDED that content developers use an address (e.g. URL) within their control combined with an identifier for the SI as the value for si-id (for example: www.wapforum.org/siid/123 or 123@siid.wapforum.org ). This parameter is required if a push_action of signal-delete is specified.
push_sinameName of the Service Indication
*push_siexpiresThis attribute may be used to specify the date and time when the SI expires and thereby be automatically deleted or marked as expired . If this attribute is not specified, the SI never expires and is thus not subject to automatic deletion. The representation for this attribute value is the same as the one used for the created attribute.
*push_initiatorThe name of the initiator of the WAP Push (appears as the originator on some handsets)

For full details on the WAP 1.2 Push Service Indication see WAP Service Indication Specification.

The example below shows a typical HTTP request for a message of this sort:

http://sms.mxtelecom.com/SMSSend?user=myusername&pass=mypassword&smsto=447700900999&smsfrom=1212&pushtype=0&push_href=http%3A%2F%2Fwww.mxtelecom.com%2F&push_action=2&push_siid=124&push_siexpires=2002-12-12&push_siname=Test+test

An example HTML form for this message type can be found here.

MMS Notification

ParameterDescription
mms_transaction_idIdentifies the notification and the subsequent transaction that is closed by the following M-NotifyResp.
mms_notification1 - Flag as a MMS Notification
mms_version1.0 - The MMS version number. According to this specification, the version is 1.0.
*mms_fromAddress of the sender. This must be in the correct format.
eg. Mobile Number: +447700900999/TYPE=PLMN
or Email Address: Joe User <joe@user.org>
*mms_subjectSubject of the message.
mms_messageclassClass of the message:
  • 80 - Personal
  • 81 - Advertisement
  • 82 - Informational
  • 83 - Auto
mms_messagelocationThis field defines the location of the message.
mms_expireLength of time the message will be available (minutes).
mms_messagesizeFull size of message in bytes. The value of this header field could be based on approximate calculation,therefore it SHOULD NOT be used as a reason to reject the MMS.

The example below shows a typical HTTP request for an MMS Notification:

http://sms.mxtelecom.com/SMSSend?user=myusername&smsfrom=Test&pass=mypassword&smsto=447700900999&mms_notification=1&mms_version=1.0&mms_from=%2B447700900999%2FTYPE%3DPLMN&mms_transaction_id=123456&mms_subject=Test%20MMS&mms_messageclass=80&mms_messagelocation=http%3A%2F%2Fmmsc.mxtelecom.com%2F/123456&mms_expire=1440&mms_messagesize=35000

An example HTML form for this message type can be found here.

Examples of requests and responses

Example of a successful submission of a single plain text message:

GET /SMSSend?user=username&pass=password&smsfrom=1234&smsto=447700900999
   &smsmsg=Hello HTTP/1.1
Host: sms.mxtelecom.com

HTTP/1.1 200 OK
Date: Wed, 05 Aug 2009 11:05:08 GMT
Server: Apache/1.3.26 (Unix) mod_ssl/2.8.8 OpenSSL/0.9.6a
Content-Type: text/plain
Transfer-Encoding: chunked

b
4316310753

0

In the above example, a message is successfully submitted to the gateway with a destination of +447700900999 and an originator of 1234. The message ID was 4316310753. Note that the numbers either side of the message id is present as a result of the "chunked" transfer-encoding and will be stripped out by a browser or other transfer agent.

Example of a successful submission of a multi-part message (containing a nokia operator logo):

GET /SMSSend?user=username&pass=password&smsfrom=1234&smsto=447700900999&split=2&
    smsucs2=004c006f00720065006d00200069007000730075006d00200064006f006c006f0072002000730069007400200
    061006d00650074002c00200063006f006e00730065006300740065007400750072002000610064006900700069007300
    630069006e006700200065006c00690074002e002000410065006e00650061006e00200061007500630074006f0072002
    00063006f006e00720020006c0069006200650072006f0020006100740020006f0072006e006100720065002e00200056
    006900760061006d00750073002e HTTP/1.1
Host: sms.mxtelecom.com

HTTP/1.1 200 OK
Date: Wed, 05 Aug 2009 11:06:14 GMT
Server: Apache/1.3.26 (Unix) mod_ssl/2.8.8 OpenSSL/0.9.6a
Content-Type: text/plain
Transfer-Encoding: chunked

16 
3408735312
3408735317

0

In the case of a forbidden operator (invalid username/password or attempting to send a reverse billing message where not allowed) the servlet will return an HTTP Forbidden error (code 403) and the body will contain an error message.

GET /SMSSend?user=username&pass=incorrectpassword&smsfrom=1234&smsto=447700900999
        &smsmsg=Hello HTTP/1.1
Host: sms.mxtelecom.com

HTTP/1.1 403 Forbidden
Date: Tue, 25 Jun 2002 12:59:31 GMT
Server: Apache/1.3.26 (Unix) mod_ssl/2.8.8 OpenSSL/0.9.6a
Content-Type: text/plain
Transfer-Encoding: chunked

20
Forbidden
 Bad username/password
0

In the case of a bad request - eg parameters missing/invalid the servlet will return a Bad request error (code 400).

GET /SMSSend?user=username&pass=incorrectpassword&smsfrom=1234
        &smsto=447700900999 HTTP/1.1
Host: sms.mxtelecom.com

HTTP/1.1 400 Bad request
Date: Tue, 25 Jun 2002 12:59:31 GMT
Server: Apache/1.3.26 (Unix) mod_ssl/2.8.8 OpenSSL/0.9.6a
Content-Type: text/plain
Transfer-Encoding: chunked

21
Bad Request
 Request type unknown
0

About MX Telecom

MX Telecom is a leader in wireless technology. MX Telecom offers an easily accessible gateway to data, voice and video messaging services including 2-way and premium SMS, multimedia messaging, interactive voice response, location-based services, video short codes, Internet and TV related solutions.

For more information, MX Telecom can be reached on 1-877-MXTELECOM (+1 877 698 3532), or via email at sales@mxtelecom.com.