White Paper
Simple, Scalable SMS Solution
This document provides information on the Bulletin Wireless Bulletin Connect service.
Executive Summary
Overview
Bulletin Connect provides your company with a simple and powerful way to communicate with mobile devices. A few lines of code are all that is needed to send and receive SMS messages through networks all over the world. Bulletin Wireless specialises in direct carrier connectivity to ensure the widest range of features are available to our clients.
Our patented temporary addressing technology enables real two-way messaging. Replies are correlated with outgoing messages, enabling sophisticated SMS applications like dispatch systems, auctions, ordering, and chat. We support a wide range of message features, including multipart messages, business cards, calendaring, and internet push.
Getting started is quick and easy. You can use your credit card to sign up online and begin sending messages immediately. If you're sending a lot of messages we offer volume discounts, and if you're in need of a billing solution, you can use ours.
Bulletin Connect; we take care of the details so that you can get on with business.
Business Challenge
Target Market
Solution Description
Bulletin Connect connects your applications to the global mobile network so we are able to provide a single point of contact for sending SMS messages to any mobile phone, worldwide.
With a range of business interfaces, Bulletin Connect ensures that integrating SMS into your applications or solutions is easy. The most popular interfaces include a SOAP based Web Service and an extremely simple, powerful and adaptive HTTP API interface.
Solution Benefits
Features and Benefits
|
Benefits
- Any SMS solution easily and quickly
- Great marketing opportunities. Send info to your mobile customer
- Gain revenue from messages your customers send to you
- Attract the public to your business through TEXT promotion
- Access to mobile phones all over the world
|
Features
- Send and receive messages (two way)
- Connect at one point to mobile phones and pagers all over the world
- Mobile originate message applications (short codes)
- Industry standard business interfaces
- Monitor your SMS solution to ensure reliability
- Full automated end to end testing
- Premium rate messages
|
Technical Specifications
Details of the proposed solution
Features
Global Access
We are a global network access provider. We connect directly to the networks to ensure that a wide range of features can be offered, and dedicate a lot of time to ensuring that our connectivity is optimized.
Short Code Support
Bulletin Connect includes full support for short codes (network specific custom numbers). We take the hassle out of set-up by working with the network providers for you.
Integrated Billing
We can handle customer billing for you, saving money and allowing you to get to market quickly.
Reply Tracking
We specialize in two-way messaging. We use our patented mTAG technology to transparently return replies to your messages.
Smart Messaging Support
With support for multipart messages, business cards, calendaring, and more, Bulletin Connect allows you to deliver a wide range of rich content, simply.
Monitoring
We provide message status notification, end to end monitoring, online logging, and load graphs to help keep your application ticking.
Application Programming Interfaces
Bulletin Connect offers two programming interfaces—SOAP, for industry standard integration with your development environment and applications, and an HTTP interface to enable simple hand-coded solutions.
HTTP
A lightweight API HTTP provides the simplicity that you're looking for. Sending a message is as easy as POSTing a web form, and receiving is as easy as getting a web page.
SOAP
An industry standard, SOAP is supported in all modern development environments. Use SOAP to address the Bulletin Connect interface in an object oriented and strongly typed manner, reducing development time and errors.
SMPP
The short message peer-to-peer protocol (SMPP) is a telecommunications industry protocol for exchanging SMS messages between Telcos's (carriers). It also allows third parties (e.g. Bulletin Wireless) to submit messages allowing us to provide carrier grade connectivity to you.
If you use a legacy SMPP system and would like to remove your reliance on one carrier and reduce your overheads then contact us and ask about our SMPP Connector.
Push and Pull Modes
We can deliver messages to your application in real time (push messaging), or you can poll Bulletin Connect to retrieve messages in batches (pull messaging).
Polling is easy to set up and to secure, and avoids problems with firewalls. Push messaging is more appropriate when low latency is critical.
Security
Both the SOAP and HTTP interfaces offer SSL security. Your application must support SSL to secure messages sent to it in push mode.
Two Way Messaging
Our patented mTAG TM technology enables real two-way messaging.
When someone replies to an SMS message, the mobile device does not tell the network which message the user is replying to. This restricts SMS applications to a flat request/reply flow, and requires that each application you run have a unique address. By associating a temporary reply address with each outgoing message we overcome these limitations.
The Problem
Consider an internet messaging application like Windows Live Messenger
or Skype. Sending SMS messages from these applications is easy, but they can't accept replies to SMS messages because it is impossible to tell who to forward the incoming messages too:
- Bob uses the chat application to send Alice a message.
- Carol uses the chat application to send Alice a message.
- The chat application forwards the messages to Alice.
- Alice replies to the message from Bob.
- Who is the message for?
You'll encounter the same problem yourself if you text two questions to a friend. They might send back two replies, or one, and they might send replies in any order:
Q:
A:
It is impossible to correlate incoming messages with outgoing messages because the protocols used to send SMS messages don't retain any information about how the messages are related to each other; hitting the "reply" button on your mobile phone doesn't tag the message you send as being a reply to the message you're viewing, it just fills out the destination number for you.
The Solution
Bulletin Connect maintains a large pool of numbers to send messages from. Every time we send a message we pick a new address from our pool and store it, along with the message and destination number, in our database. When the message arrives at its destination the "from" address that appears on the phone is the number we picked from our pool. When the user hits "reply" the "from" address is used as the destination. Then, when the Bulletin Connect receives the reply, we can correlate it with the outgoing message by looking in our database for the message with a matching pool and destination number.
To make reply tracking easy for client applications we allow them to pass an ID with each outgoing message. The correlated ID is then returned to the client with each reply.
The diagram below shows the processing path of a message from creation to reply:
|
- A client sends a message to phone number "+123456" using a chat application. The chat application assigns the message an ID and passes it to Bulletin Connect.
- Bulletin Connect assigns the message a temporary reply address from its pool of numbers. The number is stored in the database along with the destination address, the client's name, and the ID that the chat application assigned. Bulletin Connect then passes the message to the SMSC.
- The SMSC stores the message and forwards it to the destination phone.
- The recipient replies to the message. Hitting the "reply" button automatically addresses the reply to the sender (in this case using the temporary reply address assigned by Bulletin Connect). The handset passes the message to the SMSC.
- The SMSC forwards the reply to Bulletin Connect. It also passes the source (handset number) and destination (temporary reply address) of the message.
- Bulletin Connect queries the database to find the most recent message with a matching handset and pool number. It retrieves the associated client name and client ID from the database and transmits the reply, along with the ID, back to the chat application.
|
|
Examples
True two-way messaging enables a class of SMS applications that could not be built before: chat applications (as above); dispatch applications, where drivers pick jobs from lists sent to them; auction applications, where bidders reply to notifications when they're out-bid; and email to SMS bridges, to name a few.
Patents
Bulletin Wireless holds patents in the United States and New Zealand that cover this technique (US Patent #6134432 and NZ Patent #330703).
Message Types
SMS
With over 550 Billion messages sent in 2004, SMS is the workhorse of the mobile world.
Multipart Messaging
Some networks (notably GSM networks) support multipart SMS, allowing more than 160 characters to be sent to mobile devices. Where available, Bulletin Connect supports long messages transparently.
VCARD
The vcard format allows you to send contact information directly to a mobile phone's contact list. The standard, which is maintained and documented by the Internet Mail Consortium (http://www.imc.org), is supported by most phones.
VCALENDAR
Vcalendar, another IMC format, allows you to send appointments and to-do notes to phones.
WAP Push
As the number of internet ready phones increases, the demand for rich content like music, video, and games is increasing. Use WAP push messages to initiate downloads of 3G content from your application.
More Information
For the latest information about our product and services, please see the following resources:
Web Sites
http://www.bulletinwireless.com/
http://www.bulletinonline.net/
Contact Us
|
South America
Bulletin.Net
Av. Paulista, 2.300 - Andar Pilotis
01310-300 Cerqueira Cesar
São Paulo - SP
Brasil
Phone: +55 11 6847 4909
Fax: +55 11 6847 4550
sales.br@bulletin.net
|
|
All information contained within this document is protected.
Reproduction of the whole or part of this document constitutes an infringement of copyright.
Copyright Bulletin.net Inc. & Bulletin Wireless Ltd. 2004-2006
Bulletin Connect Developer Guide
Simple, Scalable SMS Solution
This document provides information on the Bulletin Wireless Bulletin Connect service.
 | Important Update - Anti-Spam
Bulletin Connect has a new anti-spam process in place. Once a mobile has sent stop to your account, they will no longer be able to receive messages from you.
To take advantage of this feature include "to STOP SMS, reply STOP" in your messages.
If you have your own proven opt-out process in place please contact Bulletin Wireless with details and we are able to exclude your account from the process.
For more information see the STOP Message Handling Process section in this document. |
Contents
Introduction
This Developer Guide provides information on the Bulletin Connect web service for application developers and software integrators.
Before using Bulletin Connect you must be setup and allocated user credentials. Complete the online application form and you will be contacted with your credentials.
While this document focuses on the simple REST like HTTP interface other options are also available if you are migrating from legacy SMPP or SOAP services.
Be sure to view the terms of service and feel free to contact us if you have any questions.
Connection Types
HTTP
A lightweight API HTTP provides the simplicity that you're looking for. Sending a message is as easy as POSTing a web form, and receiving is as easy as GETting a web page. This document focuses on this easy to use method.
 |
HTTP is the recommended interface to develop against Bulletin Connect. For additional security after debugging you can simply change to HTTPS (see below). |
HTTPS
HTTP over SSL provides the security with the simplicity of HTTP. During testing and trouble shooting we recommend HTTP for easier debugging. For your production services HTTPS is recommended.
|
HTTPS and HTTP can be used interchangably but HTTPS provides additional security. |
SOAP
An industry standard, SOAP is supported in all modern development environments. Use SOAP to address the Bulletin Connect interface in an object oriented and strongly typed manner, reducing development time and errors.
If you require more information about using the SOAP interface for Bulletin Connect please contact us.
|
The SOAP interface has been deprecated and does not support the same feature set as the HTTP interface. It is recommended that where practical you use HTTP. |
SMPP
The short message peer-to-peer protocol (SMPP) is a telecommunications industry protocol for exchanging SMS messages between Telcos's (carriers). It also allows third parties (e.g. Bulletin Wireless) to submit messages allowing us to provide carrier grade connectivity to you.
If you use a legacy SMPP system and would like to remove your reliance on one carrier and reduce your overheads then contact us and ask about our SMPP Connector.
HTTP Overview
The Bulletin Connect HTTP interface is composed of three methods
- to send messages,
- to receive messages,
- to receive receipts.
To use the API simply post method parameters to the Bulletin Connect server in the same way that a browser would submit a form.
To do this method parameters are first HTML form encoded and then submitted in an HTTP POST. This is simple and well supported in almost all development environments. Please consult the examples section for further information.
N.B. The number and order of parameters may vary. While the parameter names described in this document will not change, additional parameters may be added to the API from time to time.
Bulletin Connect Messaging URLs
| Action |
URL to Use |
| Sending Messages |
http://service.bulletinconnect.net/api/1/sms/out |
| Polling for Incoming Messages |
http://service.bulletinconnect.net/api/1/sms/in |
| Receiving Status Updates |
http://service.bulletinconnect.net/api/1/sms/status |
Sending Messages
Use HTTP POST to send messages to http://service.bulletinconnect.net/api/1/sms/out.
Recognised URL encoded parameters for sending messages are:
NOTE: The Content-Type HTTP header should be application/x-www-form-urlencoded
NOTE: If sending a UTF-16 message the Content-Type HTTP header must be application/x-www-form-urlencoded; charset=UTF-8
| Name (case sensitive) |
Description |
Required? |
| userId |
User name for authentication |
YES |
| password |
Password for authentication |
YES |
| to |
Destination MSISDN(s) |
YES
Use International Format |
| body |
Message Payload |
YES |
| messageId |
Client message identifier |
Optional. Use this if you want to take advantage of Bulletin's patented mTAGTM technology or if you want to track message status information for retrying due to errors or delays. |
| rateCode |
Message source MSISDN specifier |
Optional. Contact Bulletin for Premium Billing/Routing options |
| contentType |
The type of message |
Optional. Used for WAP Push Service Indication, vCard, vCal messages and UTF-16 SMS messages. For UTF-16 SMS messages, this must be set to text/plain; charset=UTF-16. |
| fragmentationLimit |
Integer value between 0 and 3 |
Optional. Sets maximum number of SMS message parts to use for Multipart SMS Messages, default is 0 which indicates the current maximum (3) is used |
See here for some sample HTML.
Bulletin Connect will respond to each and every HTTP request with one of the following result codes.
| Code |
Meaning |
Action Required |
| 204 |
Success! |
No action required
Note, if you use a browser to test your message syntax the browser will not show anything if you are successful. Only errors or warning will be displayed. |
| 400 |
Bad Request |
examine the HTTP header value for Status-Line for further error information |
| 401 |
Unauthorized |
Check you are using the correct URL as well as userId and password values |
| 403 |
Forbidden |
Check available funds, Check the rateCode you use is correct and that you are not setting a sender number in the request |
| 500 |
Internal Error |
Retry your message after a pause of no less than 30 seconds and if it continues please Contact Bulletin Wireless |
The userId and password are supplied to you by Bulletin Wireless when you sign up for a Bulletin Connect account. You may pass them to the server as form encoded parameters, or in the HTTP Authorization header in Basic format.
The to parameter is the destination Number/MSISDN (Mobile Station ISDN number), i.e. the phone number to send the message to, including the country code. Do not include leading zeros, spaces, brackets or other formatting characters. To send a message to multiple recipients list the numbers, separated by spaces, in the to parameter (then URLencode).
Do not POST multiple to parameters.
The body parameter is used to pass the message. Messages can be up to 160 characters long. The allowable character set may vary depending on the destination network. In general characters from the GSM default character set are safe (see GSM 03.38). For UTF-16, messages can be up to 70 Unicode characters long which must be UTF-8 encoded (before URL Encoding). That is, for UTF-16 messages the body parameter must be UrlEncode(UTF8Encode(Unicode message)) this will be sent through as UTF-16 to the handset.
The messageId is a free form string used to correlate messages with replies and read receipts. Any printable ASCII character can be used in the string, and it can be up to 36 characters long. The messageId will be returned to your application with receipts and replies.
The rateCode parameter is optional. It can be used to specify the source number of a message. If you wish to specify a source number for your messages Contact Bulletin Wireless for setup details.
When using a rateCode to send a message ensure you use the actual rateCode that was provided by Bulletin Wireless (this will not generally be a number).
The contentType specifies the type of message to send. Supported message types include vCard, vCalendar, and WAP service indication (see Extended Messaging section for more information). If not specified it defaults to text/plain.
Receiving Messages
There are two ways to receive messages from Bulletin Connect.
- You can either poll the server for incoming messages (pull method), or
- have incoming messages sent (pushed) to your server as they are processed.
Polling is 'firewall friendly' and often easier to implement (especially if you are working outside an HTTP server)
To Receive a Message
Clients can GET incoming messages from http://service.bulletinconnect.net/api/1/sms/in.
Required Input parameters are:
| Name (case sensitive) |
Description |
Required? |
| userId |
User name for authentication |
YES |
| password |
Password for authentication |
YES |
The userId and password are supplied to you by Bulletin Wireless when you sign up for a Bulletin Connect account. You may pass them to the server in a query string, or in the HTTP Authorization header in Basic format.
Bulletin Connect will respond to each and every HTTP request with one of the following result codes.
| Code |
Meaning |
Action Required |
| 200 |
OK (normal result) |
Parse the results for the incoming message details as described below |
| 204 |
No content (no messages) |
No incoming messages. Pause processing and retry after 30 seconds |
| 401 |
Unauthorized |
Check userId and password |
| 405 |
Incorrect Connection Method Used |
Use the HTTP GET Method rather than POST |
| 500 |
Internal Error |
Contact Bulletin Wireless |
For 200 codes (success) Bulletin Connect will include a form encoded parameter list containing some or all of message information as described here
| List Item |
Description |
Notes |
| messageId |
A unique identifier for the message |
Bulletin Connect Unique ID. Check this ID to ensure you have not already processed this incoming message (50 character (max) string). |
| from |
Source MSISDN |
The sender of the SMS message in International format |
| to |
Destination MSISDN |
The number the message was sent to. Applies to MO messages only, not to reply messages. |
| rateCode |
The rate code for the short code the message was sent to (if applicable) |
| inReplyToId |
Correlation ID (if the message is a reply) |
Matches the messageId sent by you in an outbound message.
If no messageId was set then this will contain default. |
| body |
Message Content |
URL encoded content of the users message |
N.B. The order of the parameters may change so use value/pair matching rather than location mapping.
Example GET Request
Substitute your correct Bulletin Credentials for this in this example and if you have any incoming messages queued on Bulletin Connect then you will download one of them if you access the URL in a browser.
Example Mobile Initiated Message Content
This shows the content of the request when the messages is not a reply but has been initiated by the handset.
Note the rateCode and to values included in the content.
Example Content for Reply Messages
This shows the content of the request when the messages is a reply to one you sent previously.
Note the inReplyToId which will map to the messageId you set in your original outbound message.
This is the same message when you do not set the messageId you set in your original outbound message.
| Handy Hint
To take advantage of the patented 2-way SMS message threading ensure that you set a unique messageId in your outbound message and match it with the inReplyToId in the incoming message. |
To Receive a Message Receipt
Clients can GET incoming receipts (status updates) from http://service.bulletinconnect.net/api/1/sms/status or provide a endpoint for Bulletin to push the receipts to.
Required Input parameters are:
| Name (case sensitive) |
Description |
Required? |
| userId |
User name for authentication |
YES |
| password |
Password for authentication |
YES |
The userId and password are supplied to you by Bulletin Wireless when you sign up for a Bulletin Connect account.
Bulletin Connect will respond to HTTP requests with one of the following result codes.
| Code |
Description |
Notes |
| 200 |
OK (normal result) |
Parse the results for the incoming status details as described below then repoll to get another status |
| 204 |
No content (no messages) |
No status messages waiting. Pause processing and retry after 30 seconds |
| 401 |
Unauthorized |
Check userId and password |
| 405 |
Incorrect Connection Method Used |
Use the HTTP GET Method rather than POST |
| 500 |
Internal Error |
Contact Bulletin Wireless |
For 200 codes (success) Bulletin Connect will include a form encoded parameter list containing status information for a single message as described here
| List Item |
Description |
Notes |
| messageId |
A unique identifier for the receipt |
Bulletin Connect Unique ID. Check this ID to ensure you have not already processed this status update (50 character (max) string). |
| to |
A MSISDN or Short Code from Bulletins threading range |
| from |
Destination MSISDN of message |
The recipients number of an outbound message sent by you (international format). |
| statusCode |
Message status |
See Message Status Codes for simple descriptions of Codes used |
| inReplyToId |
Correlation ID of the message |
Matches the messageId sent by you in an outbound message.
If no messageId was set then this will contain default. |
| error |
Descriptive text |
More (readable) information about the Message Status |
N.B. The order of the parameters may change so use value/pair matching rather than location mapping.
Message Status Codes
Possible values of statusCode are:
| Code |
Basic Description |
What this means to your Application |
Final Status? |
| NUR |
Number Unreachable |
Check the number is correct and in International Format and then resend. The error string will also provide some more useful information such as whether the recipient is blocked. Be careful about infinite loops, only retry a couple of times. |
Yes |
| SNT |
Message Passed to Network |
Wait. Give it a few minutes and then poll for more Status Messages. |
No |
| ERR |
Internal Error |
An error occurred. It may be recoverable so try sending the message again in a few minutes. Be careful about infinite loops in your code. |
Yes |
| NRCV or NRC |
Not Received |
Check the number is correct and in International Format and then resend. Be careful about infinite loops though. |
Yes |
| RCV |
Message Received |
Excellent. This is a final status for this message and the handset has received it. |
Yes |
| EXP |
Message was not delivered within allowed time |
This is a final status for this message and the handset has not received it. Retry if you want but for a lot of carriers this status may take days to return so the message may no longer be relevant. |
Yes |
| INF |
Insufficient funds |
A billing error has occurred. If you get this error then your Bulletin Online account has reached its credit limit. This is very rare and you need to contact Bulletin Wireless immediately. No more messages can be sent until this is rectified. |
Yes |
| Handy Hint
To ensure you know the current status or your SMS message, ensure that you set a unique messageId in your outbound message and correlate it with the receipts (inReplyToId field) as you process them. |
| Handy Hint - 2
For messages to multiple recipients (in a single POST) your messageId will be the same for each recipient. Therefore you should use a dual key of the messageId and the from fields to track individual replies and status updates. |
Message Re-transmission
If message transmission fails for any reason Bulletin Connect will resend the message after a short delay (by default one minute). In rare circumstances this can lead to your application receiving duplicate messages.
The messageId of each incoming message and each status message is guaranteed to be unique, so your application can use it to detect re-transmitted messages and reject duplicates.
STOP Message Handling Process
Bulletin Connect will add any handset that sends a stop message to a blocked list. This automated process will then prevent that handset from receiving any more messages from the Bulletin Connect account concerned.
When a stop SMS request is processed, Bulletin Connect will also send an email to the contact address for the Bulletin Connect account and send a reply SMS to the handset telling them that they will no longer receive any messages from your SMS service.
Any further attempts to send to the blocked number will result in a NUR status with an appropriate error description.
Actions and Alternatives
- How to remove a number that was added in error?
- If you believe that a SMS response was not a true opt-out request then ask the recipient to contact us by phone quoting your Bulletin Connect Account ID and we will remove them from the blocked list.
- What if I have my own opt-out process in place?
- If you have a proven opt-out process in place, that we feel is suitable, then we are happy to remove you from this process. If we do that then you will still get an email when we detect a stop request but we will not send any confirmation SMS to the handset or block any future messages to that number.
- Can I see a list of numbers that have opted out of my messages?
- Sorry, no. The recipient has asked that they no longer receive messages from you therefore we do not want to provide you a list of these numbers that you can then potentially use elsewhere. If you have a specific number that you want clarified then please contact us and we will see what we can do to assist.
To Have Messages POSTed to Your Server
Contact the Bulletin Wireless services team and tell them the details of the URL you would like messages to be sent to and when messages and receipts arrive they will be POSTed to your URL using the form parameters used in Reply processing.
N.B. Bulletin Connect will keep re-transmitting messages if your application returns any result code other than 200 (OK) or 204 (No Content), or if the post fails.
Extended Messaging
Bulletin Connect supports the following extended message types
- Multipart SMS Messages
- WAP Service Indication
- vCard (electronic business card)
- vCalendar (events and appointments)
Multipart SMS Messages
Single SMS messages can not be more than 160 (7 bit) characters or 70 (16 bit) unicode (UCS2) characters in length, which may restrict the content that can be sent to phones.
To work around this problem, a standard has been developed that allows multiple SMS messages to be concatenated on a phone and presented to the user as one (long) message. This is known as Segmentation and Reassembly or concatenated SMS. Please note, not all handsets or carriers support concatenated SMS.
Bulletin Connect uses the message sending parameter fragmentationLimit to set the maximum number of parts to use. If this parameter is set, you will not be able to exceed the character limits listed in the table below. For example, passing parameter name="fragmentationLimit" value="2" will restrict the number of characters to 306 (7 bit) or 134 (16 bit).
| SMS Parts |
7 bit Length |
16 bit Length |
| 1 |
160 |
70 |
| 2 |
306 |
134 |
| 3 |
459 |
201 |
In order to maintain maximum compatibility with handsets, Bulletin Connect limits the number of parts in a concatenated SMS to 3. If the content exceeds your limit or exceeds the system limit Bulletin Connect will return a 400 error.
WAP Service Indication
Used to send any URL to an internet enabled phone, service indications are ideal for delivering content such as media (images, sound or video) and delivering basic web pages (XHTML or WML format) that can contain text and media in a richer format than available via SMS.
Service indications are sent the same way as plain SMS messages, but with a contentType of application/vnd.wap.sic. The URL is XML formated and URLencoded (as with all parameters used) and sent to Bulletin Connect in the body parameter of the message sending POST:
Set the href attribute to the full web address (URL) of your content and the body text of thetag to a description of the content.
Different handsets handle service indication messages differently but basically the recipient will receive a SMS alert that shows the description you set in your message. They can then open the page (URL) you set using their mobile browser.
See http://service.bulletinconnect.net/demo/indicator.html for a demonstration webpage that shows the HTTP interface for sending Service Indication messages. You can view the source for this page here.
vCard (electronic business card)
Used to send contact details to a handset, vCards are sometimes referred to as "business cards."
The vCard specification is maintained by the Internet Mail Consortium here: http://www.imc.org/pdi/. It is a simple text based format that looks something like this:
vCards are effectively plain messages with the vCard details URL encoded and with a contentType parameter of text/directory when sending the message POST .
Multiple vCards can be sent in a single POST but you will need to ensure you set the fragmentationLimit to a proper level for the message to be delivered.
N.B. Different handsets have different levels of support for the vCard "standard" so try your message on a variety of handsets to see if you need to make adjustments to the information you provide.
vCalendar (events and appointments)
vCalendar messages are used to send appointments and reminders to a phone.
The standard is similar to the vCard standard and is also maintained by the Internet Mail Consortium. It is a simple text based format that looks something like this:
vCalendar messages also need to be URL encoded and sent the same way as other Bulletin Connect messages, but with a contentType of text/calendar.
Multiple VEVENT appointments/events can be sent in a single vCalendar POST but you will need to ensure you set the fragmentationLimit to a proper level for the message to be delivered.
Hints and Tips
- Remember to URL encode all parameters, especially the body parameter which will often contain characters that aren't allowed in form encoding.
- When serving content with WAP push make sure that your web server presents the correct mime types for your content.
- Wrap content in WML pages for a better user experience.
- Multipart messages are charged per part.
- Read the FAQ
- Extended messaging to CDMA networks is not currently supported (we will add support in the future).
SDK
