Allows you to send a single message to one or more recipients or groups (as defined in your phone book).

Note on HTTP connections: please limit yourself to one concurrent connection, i.e., in your code, send with only one thread/process. If you feel that you have latency problems (if your computer is far away from our server in network terms), you could consider using HTTP KeepAlive.

Example: http://www.sms.studentmessenger.co.uk:5567/eapi/submission/send_sms/1/current?username=john&password=
abcd1234&message=Hi+Mom&msisdn=44123123456,44123123457

Required parameters

• username
• password
• message: max 160 chars for text, max 280 chars for 8bit
• and one of:
  • msisdn: comma-separated list of recipients or
  • dest_group_id: comma-separated list of numeric group ids (we recommend a maximum of 5000 recipients across all groups to minimise timeouts)

Optional parameters

• sender: sender id (if alphanumeric, max 11 characters). This facility has to be specifically enabled for your account on request. Alphanumeric sender id is a route-specific feature.
• msg_class: currently 0 (flash SMS) or 2 (normal SMS), default 2
• dca: Data Coding Alphabet: 7bit,8bit or 16bit, default 7bit (normal text message). For 8bit (ringtones,logos) or 16bit (Unicode), a message containing only hexadecimal octets, to a maximum of 280 characters (140 octets), must be submitted. Currently, concatenation is not supported for Unicode messages. 16-bit is a route-specific feature.
• want_report: 0 or 1, default 0
• routing_group: (previously known as cost_route, which still works to be backwards compatible) - possible values are 1,2,3 (it is possible but unlikely that these values could change - if they do, you should be contacted first). The current default is 2, but you would be wise to not depend on this remaining so. Routing groups group delivery routes by cost or quality.
• source_id: an alphanumeric (plus other common characters) id, for your own accounting purposes (e.g. useful if you have subaccounts that you send messages on behalf of, or even if you have your own unique id that you want to associate with the message). Max 20 characters.
• repliable: 1 to enable, 0 to disable, default is not set, which means that your User Profile's default repliable setting will prevail. Also see discussion on repliability below.
• strip_dup_recipients: set to 1 to enable, default is 0. Normally we return an error if your list of recipients is not unique. This setting causes the duplicates to rather be stripped and the messages be sent. Not recommended: you should rather validate your data properly.
• stop_dup_id: see section on eliminating duplicates below.
• send_time: scheduled send time (see section on scheduling below), in format yyyy-mm-dd hh:mm:ss.
• send_time_seconds: scheduled send time in integer format. This is an alternative to send_time, and represents the number of seconds since 1 Jan 1970, also known as unixtime.
• scheduling_description: if using scheduling, you could provide a description of the scheduled job here to later help identify it (viewing of scheduled jobs is not yet supported though).
• test_always_succeed: for testing purposes - if set to 1, does basic validation (username, password, etc) of your submission, but stops short of actually submitting the messages, and returns a successful status code as if it had submitted them successfully.
• test_always_fail: as for test_always_succeed, but after basic validation, always returns a failure code.
• nodup: (deprecated: you should rather use stop_dup_id) set to 1 to enable, default is 0. It is possible, if your HTTP connections time out, for duplicate messages to be sent from your account. This option will strip any duplicate messages(identical msisdn and body) within a certain period, in region of 10 minutes. Use with caution: often duplicates are intentional, e.g. requesting a certain service, and re-requesting it shortly afterwards.

Returns:

status_code|status_description|message_id (where message_id is optional, depending on the error)

Possible values for status_code are:

• 0: In progress (a normal message submission, with no error encountered so far).
• 1: Scheduled (see Scheduling below).
• 22: Internal fatal error
• 23: Authentication failure
• 24: Data validation failed
• 25: You do not have sufficient credits
• 26: Upstream credits not available
• 27: You have exceeded your daily quota
• 28: Upstream quota exceeded
• 40: Temporarily unavailable

You should never depend on the value of status_description - only depend on status_code, which is a constant. However, status_description can contain useful information about the nature of failures when you are developing your initial application. message_id is guaranteed to be a positive integer > 0, if present.

Note: you should attempt to resend if you receive status code 40. You could also do so if you receive 26 or 28, which might have been resolved after several resend attempts. All other errors should be considered fatal.

Any HTTP status code other than 200 should be considered transient, i.e. you should attempt to resend after some interval.

URL

The following url will ensure you always connect to the latest available send_sms version:
URL: http://www.sms.studentmessenger.co.uk:5567/eapi/submission/send_sms/1/current

(this should always be backwards compatible, but conservative high volume users could use the specific version).
Current version-specific send_sms URL:
URL: http://www.sms.studentmessenger.co.uk:5567/eapi/submission/send_sms/1/1.2

Repliability

Repliability is a feature whereby the originating address (sender id) of a message is set to a number at which we will collect replies on your behalf, and make them available to you. The feature of repliability will not necessarily be possible on your account or for your destination(s). Also be aware that we may not have reply numbers available for your specific country, which means that persons who reply may be exposed to higher costs than those of sending SMSs in their own country, and poorer delivery speed may also result. The repliable parameter is incompatible with the sender parameter. Additionally, this parameter will override any default sender id which you may have set up on your account.

Scheduling

Scheduling allows you to specify that a message be sent at a future date. Credits will be deducted immediately from your account, and once submitted, such a message cannot be cancelled.

If you specify a date/time in the past, your message will be sent immediately, and a status code of 0 will be returned. If you correctly specify a future date for sending, you will receive a status code of 1. Thereafter, you will not be able to request the status of a scheduled message until after it has actually been sent. The date that you supply must be in the time zone that your account is configured for.

If the destination is a group, the group members will be determined at the time that you submit the message, and not at the time the message is scheduled to be sent.

Please be sure to check our Terms and Conditions for any special conditions that may apply to scheduled messaging, e.g. adjustments that may need to be made for significant price changes where messages are scheduled far into the future.

Eliminating duplicates

Consider the case where you submit a message, but experience a network timeout (or your application crashes). Your application cannot know if we received and processed the message or not, and you are forced to resubmit it, possibly generating duplicates. If the message was to many recipients, this can be serious.

By submitting a unique id of your own along with every message that you submit, you can safeguard against this. The optional parameter stop_dup_id takes an integer as an argument, in the range 1 to 2147483647. If you submit a message with a stop_dup_id that you have recently (within the past few hours) used in another submission, then that submission will not be processed, and you will receive the response to the original submission, e.g.:
0|IN_PROGRESS|30430
or:
25|FAILED_USERCREDITS|30430

(where 30430 is the message_id that was generated by the original submission)

In other words, the process is entirely transparent to you, and you will never know whether or not your submission was processed the first or the second time. Note that, had you received the second response above (FAILED_USERCREDITS), you would probably want to resubmit at a later date in the hope that your credits had been topped up in the interim. When you do so, be sure to use a new stop_dup_id!

Route-specific features

Some features depend on how messages are routed, which again depends on certain pricing options which may have been applied to your account. Please contact us to find if such a feature is available to you, if unsure.

---

ChangeLog

5-Aug-2004 Added stop_dup_id. 28-Jul-2004 Added scheduling. 23-Jul-2004 Added source_id to existing v1.2; removed unused msg_id parameter. 18-Jun-2004 Added strip_dup_recipients to existing v1.2 25-Mar-2004 send_sms: renamed cost_route parameter to routing_group, with cost_route now an alias to routing_group. 9-Feb-2004 Added support for Greek and extended GSM characters. 30-Jan-2004 quote_sms version 1.1 published (note: several changes in URL). Added costing for messages to groups (dest_group_id). 22-Jan-2004 send_sms version 1.2 published. Added sending to groups (dest_group_id). 15-Jan-2004 added repliability options to existing version 1.1 of send_sms. 27-Aug-2003 added new cost_route options new optional param: nodup new faster url