This section provides additional information on using the Vodafone SMS Messaging Interface.
This API uses Basic authentication with username, password, and firewall whitelisting.
About the parameters
- customerID corresponds to your account ID. Vodafone assigns this to you during the provisioning process. See also: About Customer IDs.
- registrationId is used to identify your web application. It is used when retrieving SMS messages.
- senderAddress is a short code that identifies the application sending the SMS message (the originating party's address). It is what appears as the "from" address on the handset.
- subscriptionId is used to indicate the delivery status of a message.
About Customer IDs
- When the web application that sends SMS messages is set up with a unique customer ID, the URI address it uses to send these messages changes. However, the way it sends these messages (the HTTP request) stays the same.
- The customer ID helps in identifying the application and makes some parts of the message-sending process, such as the senderAddress verification, less strict.
- The customer ID should also be used in the web addresses for checking incoming messages.
Character encoding support
Inbound messages are submitted to the platform as either a UTF-8 or UTF-16 string. The method can be selected using a standard HTTP header. The platform offers following encoding methods for text messages sent to the devices:
|If the characters in the submitted message are
|Within 7-bit GSM alphabet
|The message will be automatically encoded as 7-bit GSM message.
The message payload for these messages will be 160 characters per message segment.
|Outside 7-bit GSM alphabet
|The message will be automatically encoded as 16-bit UCS-2 (Unicode) message.
The message payload for these messages will be 70 characters per message segment.
If the messages sent exceed the character limits: concatenated messages
If the messages sent exceed the character limits listed in the table, the message will be segmented into multiple SMS fragments. This is called concatenated SMS.
Each fragment of the concatenated SMS is managed by the service as a unique separate message, with a header indicating that it is part of a concatenated message.
Message fragments are then re-constituted on the end device, using headers, into what appears to be a single long message.
Concatenated message fragments are delivered and billed separately. This will result in a higher billing charge, and multiple message deliveries to the end device.
About message segmentation
SMS is designed to send up to 140 Octets. By default, a single SMS message can contain up to 160 characters, as it is encoded using the GSM 7-bit alphabet.
If the message contains non-GSM 7-bit alphabet characters
If the message contains non-GSM 7-bit alphabet characters, then the message payload will be encoded using UCS-2. You can send a maximum of 70 characters in a single UCS-2 SMS message.
If the message exceeds 160 or 70 UCS-2 characters: Segmentation and reassembly (SAR)
If the SMS message exceeds 160 or 70 UCS-2 characters, then the message must be segmented into multiple SMS messages. Each message segment is submitted individually by the customer. The receiving handset will be able to combine the messages with the original message. This is called Segmentation and Reassembly (SAR)
When Sending Multipart SMS Messages, You Will Be Charged For Every Single SMS Message Part Sent.
About the User Data Header (UDH)
The User Data Header (UDH) is a part of this message that contains extra information needed to deliver the message correctly. The UDH takes up some space in the message: it uses 7 octets. This means you're left with 133 octets for your actual message. If you're using a character encoding that requires 2 octets per character, you can only fit 66 characters in your message.
The API allows an application to set a specific web address where it will receive two types of messages: P2A messages, and Delivery Receipt messages. If the application chooses to get notifications about incoming messages through a designated URL (called notifyURL), any messages received will be automatically sent to this URL using the HTTP POST method.
NotifyURL is the dynamic URL for incoming SMS/DLR.
The API supports receiving P2A SMS messages sent to the application, using either:
- a poll mechanism, or
- by subscribing to notifications.
|If the following is required
|The application must include the URL to which the delivery receipt is sent.
|The notifyURL parameter must be sent within the receiptRequest element.