Difference between revisions of "DLRIntro"
Line 1: | Line 1: | ||
− | Message Delivery Confirmations (DLR) are receipts that indicate status of messages you submitted. You can think of them as electronic signatures, that receiving handset sends back to the sender, informing the sender of the | + | |
+ | == Message Delivery Confirmations (DLR) == | ||
+ | |||
+ | |||
+ | Message Delivery Confirmations (DLR) are receipts that indicate status of messages you submitted. You can think of them as electronic signatures, that receiving handset sends back to the sender, informing the sender of the status of the message. This is similar to a human signature upon receipt of a "registered' piece of mail. Unfortunately, DLR is not available by all networks (notably, networks in USA, Canada and Mexico often do not issue DLR's) which significantly reduces the value of this service. Please make sure that you can live with false negatives (the message is delivered but you get no confirmation) before implementing this service. We implement two options for getting DLR's (if and where available) | ||
* HTTP-PUSH | * HTTP-PUSH |
Revision as of 00:52, 14 September 2011
Message Delivery Confirmations (DLR)
Message Delivery Confirmations (DLR) are receipts that indicate status of messages you submitted. You can think of them as electronic signatures, that receiving handset sends back to the sender, informing the sender of the status of the message. This is similar to a human signature upon receipt of a "registered' piece of mail. Unfortunately, DLR is not available by all networks (notably, networks in USA, Canada and Mexico often do not issue DLR's) which significantly reduces the value of this service. Please make sure that you can live with false negatives (the message is delivered but you get no confirmation) before implementing this service. We implement two options for getting DLR's (if and where available)
- HTTP-PUSH
- SOAP PULL
1. Push
Messages received in your account are forwarded to you using email or HTTP-POST. This is the preferred method as you get messages immediately after they have been received. For this process to work you need to expose an HTTP-POST listener on your web server and let us know its URL. The downside of this method is in case your URL changes (for example you have dynamic IP address) forwarding to your application will stop as we will unable to locate the URL that was provided - for as long as you do not update the URL with new IP address. Also, this method is sensitive to firewall settings (you will need to expose the web server which may be behind the the firewall - make sure the port is open). See below links for details on using HTTP-POST:
PLEASE NOTE - YOUR APPLICATION MUST IMPLEMENT HTTP-POST processing NOT HTTP-GET
Step-By-Step Process to Get You Going
- We assume that you already created an account and have sending using API working
- Create HTTP-POST listener in your server. Make sure it is on a publicly accessible web server (i.e. external services can access your application)
- Login to your account and click on the Contact Us link. Paste the URL into the body of your message and request that we configure your account
- Once you receive confirmation of this completion, you will be able to receive messages in y application
2. Pull
Your application can also collect messages from your online account in periodic intervals. This is preferred if you do not have an application that can be exposed to the Internet or if your IP address changes often so that it is not practical to keep updating your IP/URL settings. The downside is that you need to poll for new messages every so often (no more than 2 minute intervals are allowed), which means that delivery to your application may be slightly delayed.
Using SOAP method GetNewInboxMessages or using standard POP3 protocol.