Infobip HTTP API and SMPP Specification
Infobip HTTP API and SMPP Specification
MODIFIED: 06/11/2014
CONTENTS
1 Introduction......................................................................................................................................... 3
2.1 Introduction................................................................................................................................. 4
2.2.1.1 XML......................................................................................................................... 4
2.2.1.4 Examples............................................................................................................... 9
2.2.2.4 Examples.............................................................................................................15
2.2.4 Examples:.........................................................................................................................22
1 Introduction
This document provides developers with instructions for integrating SMS messaging services into various solutions
using Infobip HTTP application programming interface (HTTP API). Infobip HTTP API can be used for sending SMS
messages, collecting delivery reports, making Network Query (NQ) requests and receiving inbound SMS messages
sent from mobile phones.
Along with Infobip HTTP API specifications, this documentation also provides Infobip SMPP specifications, including
connection to Infobip SMPP server, bind options and specifications for sending number context requests over SMPP.
The first chapter thoroughly describes Infobip HTTP API methods, describing methods, URLs and parameters needed
as well as providing practical samples. The following API methods are available:
++ Send messages using HTTP, XML and Plain methods are available
++ Collect delivery reports collect XML-formatted delivery reports for sent SMS messages
++ Network Query (NQ) - enables the identification of the network that a mobile phone number belongs to, and the
status of a mobile number; includes asynchronous and synchronous number context requests over HTTP
++ Receive messages using HTTP GET collect SMS messages sent by your customers GSM phones
The second chapter describes general Infobip SMPP specifications which can be used by your applications/solutions.
Also, it describes how to send number context requests over SMPP protocol, providing samples of delivery reports
which contain IMSI, as well as a number of optional parameters depending on your client package.
2.1 Introduction
The Infobip system offers various methods to send and receive SMS messages. This chapter contains specifications for
the following methods:
++ Send messages using HTTP XML with this method it is possible to send SMS messages to a number of recipi-
ents using XML-formatted data sent to a corresponding URL.
++ Send messages using HTTP Plain similar to the previous method, this method allows sending SMS messages
passing parameters directly as query string variables.
++ Collect delivery reports gives you the ability to collect XML-formatted delivery reports from sent SMS messag-
es using either the push (HTTP POST method to a predefined call-back URL) or the pull method (by making HTTP
GET request to a corresponding URL).
++ Number Context the Infobip system also offers the Number Context solution. This service deals with Mobile
Number Portability (MNP), enabling the identification of the network that a mobile phone number belongs to, and
the status of a mobile number. It includes asynchronous and synchronous Number Context requests over HTTP.
++ Receive messages using HTTP GET by using this service, you can collect SMS messages sent from your cus-
tomers GSM phones. For example, Infobip can host your GSM SIM card on its GSM modem farm. Inbound mes-
sages are then forwarded to a call-back URL (using HTTP GET method), which must be prepared on your web
server.
2.2.1.1 XML
There are two ways of formatting the XML string, with custom or Infobip generated message id.
Request
POST http://api.infobip.com/api/v3/sendsms/xml
Host: api.infobip.com
Content-Type: application/xml
Accept: */*
XML= XML=
<SMS> <SMS>
<authentication> <authentication>
<username>account_username</username> <username>account_username</username>
<password>account_password</password> <password>account_password</password>
</authentication> </authentication>
<message> <message>
<sender>Infobip</sender> <sender>Infobip</sender>
<text>Hello</text> <text>Hello</text>
<flash></flash> 1
<flash></flash>1
<type></type> <type></type>
<wapurl></wapurl> <wapurl></wapurl>
<binary></binary> <binary></binary>
<datacoding></datacoding> <datacoding></datacoding>
<esmclass></esmclass> <esmclass></esmclass>
<srcton></srcton> <srcton></srcton>
<srcnpi></srcnpi> <srcnpi></srcnpi>
<destton></destton> <destton></destton>
<destnpi></destnpi> <destnpi></destnpi>
<sendDateTime>4d3h2m1s</sendDateTime> <sendDateTime>4d3h2m1s</sendDateTime>
<ValidityPeriod></ValidityPeriod> <ValidityPeriod></ValidityPeriod>
<appid></appid> <appid></appid>
<pushurl></pushurl> <pushurl></pushurl>
<nopush></nopush> <nopush></nopush>
<recipients> <recipients>
</recipients> </recipients>
</message> </message>
</SMS> </SMS>
As shown in the XML formats described above, XML formatted with custom message id contains a different <gsm> tag
which includes the messageId attribute. That is the main difference between these two formats and it means that when
using XML formatted without custom message id tag, it is possible to collect delivery reports from sent SMS messages, but
those reports will have messageId generated by the Infobip system. Therefore connecting the delivery report with its SMS
message will not be possible.
On the other hand, when using XML formatted with custom message id, each delivery report will contain the
messageId attribute with a value equal to the value of the messageId attribute defined by the client in <gsm> tags of
every recipient in XML formatted with custom message id. This is useful if the client wants to collect delivery reports for
specific SMS messages and it can be done by using messageId of those messages (for more details about collecting
delivery reports see chapter 0).
UNICODE messages can be sent either by converting message text into hexadecimal representation and inserting that
content into <binary> tag or by inserting unconverted UNICODE text into <text> tag. In case when youre inserting
unconverted UNICODE text you have to relay Content-Encoding:UTF-8 information in the header when submitting
messages using HTTP POST. No matter which method you use to submit UNICODE messages you always have to set
<DataCoding>8</DataCoding> parameter.
flash Can be 0 or 1:
0 sends a normal SMS
1 sends Flash SMS
Example: www.infobiiip.com/something.jpg
Example: 410A0D4243
Esmclass Esm_classparameter.
Default value: 0
sendDateTime Used for scheduled SMS (SMS not sent immediately but at scheduled time).
4d3h2m1s means that message will be sent 4 days, 3 hours, 2 minutes and 1 second from now.
Youre allowed to use any combination and leave out unnecessary variables.
appid If value is not received all DLR-s without appid will be sent when client send pull request with no appid
specified. If value is received only DLR-s with given appid will be delivered when client pulls reports for
that appid.
pushurl* If value is not received or received value is nopush all DLR-s without pushurl will be pushed to default
URL set for your account. If value is received DLR is sent to the given URL (sent as pushurl value), rather
than to the default one set for your account.
nopush* If value is not received or received value is 0 all DLR-s with nopush=0 will be pushed, as usual. If value
is received and received value is 1 all DLR-s with nopush=1 will not be pushed, and will be available for
pull.
Example: 41793026727
Pushurl and nopush combinations: If pushurl value is not empty and nopush=0, DLR will be pushed. If pushurl
value is not empty and nopush=1, DLR will not be pushed.
Unknown 0 Unknown 0
Alphanumeric 5 National 8
Private 9
Abbreviated 6
ERMES 10
Internet (IP) 14
WAP Client Id (to be defined) 18
For example,
if you want to send a message with the originator (sender name) 12345 (note, no leading +),
you should indicate src-ton = 2 (national), src-npi = 1.
If you want to add the leading + in the originator,
you should use src-ton = 1 (international), src-npi = 1.
If you want to use the alphanumeric originator, please set src-ton = 5 (alphanumeric), src-npi = 0.
If you do not specify src-ton and src-npi parameters,
your message will be sent with src-ton = 1for numeric sender, and src-ton = 5 for alphanumeric sender.
After the POST XML is initiated by the client, some response codes will be available. Variable parts of the XML structure are marked
black.
The return XML string format will be as follows, for successful request:
<results> <results>
<result> <result>
<status>0</status> <status>0</status>
<messageid>Infobip_MessageId</messageid> <messageid>clientmsgID1</messageid>
<destination>38595111111</destination> <destination>38595111111</destination>
</result> </result>
</results> <status><0</status>
<messageid>clientmsgID2</messageid>
<destination>38595222222</destination></
result>
</results>
<results> <results>
<result> <result>
<status>-13</status> <status>0</status>
<messageid></messageid> <messageid>clientmsgID1</messageid>
<destination>000000000000</destination> <destination>38595111111</destination>
</result> </result>
</results> <result>-13</status>
<messageid>clientmsgID2</messageid>
<destination>000000000000</destination></
result>
</results>
1.a Send short message to a single number 1.b Send short message to many numbers
Request Request
<SMS> <SMS>
<authentication> <authentication>
<username>test</username> <username>test</username>
<password>test</password> <password>test</password>
</authentication> </authentication>
<message> <message>
<sender>Infobip</sender> <sender>Infobip</sender>
<text>Hello</text> <text>Hello</text>
<recipients> <recipients>
<gsm>385951111111</gsm> <gsm>385951111111</gsm>
</recipients> <gsm>385952222222</gsm>
</message> <gsm>385953333333</gsm>
</SMS> </recipients>
</message>
</SMS>
Reponse Reponse
</result> <status>0</status>
<result> <messageid>032052214394832214</messageid>
<destination>385952222222</destination>
</result>
<result>
<status>0</status>
<messageid>092052214394831436</messageid>
<destination>385953333333</destination>
</result>
</results>
VER : 07.11.2014. 9/38
2. a Send Long SMS 2.b Send Scheduled SMS
Request Request
<SMS> <SMS>
<authentication> <authentication>
<username>test</username> <username>test</username>
<password>test</password> <password>test</password>
</authentication> </authentication>
<message> <message>
<sender>Infobip</sender> <sender>Infobip</sender>
<text>LongSMSTestLongSMSTest <text>Hello</text>
LongSMSTestLongSMSTestLongSMSTestLongSMS
<sendDateTime>4d3h2m1s</sendDate-
TestLongSMSTestLongSMSTestLongSMSTestLon Time>
gSMSTestLongSMSTestLongSMSTestLongSMSTest <recipients>
LongSMSTestLongSMSTestLongSMSTest</text>
<gsm>385951111111</gsm>
<type>longSMS</type>
</recipients>
<recipients>
</message>
<gsm>385951111111</gsm>
</SMS>
</recipients>
</message>
</SMS>
Request Request
<SMS> <SMS>
<authentication> <authentication>
<username>test</username> <username>test</username>
<password>test</password> <password>test</password>
</authentication> </authentication>
<message> <message>
<sender>Infobip</sender> <sender>Infobip</sender>
<text>Dear mister Juri..</text> <text>Hello</text>
<datacoding>8</datacoding> <datacoding>240</dataCoding>
<recipients> <recipients>
<gsm>385951111111</gsm> <gsm>385951111111</gsm>
</recipients> </recipients>
</message> </message>
</SMS> </SMS>
Message Id parameter will be either generated by Infobip, or it can be customized, by adding messageId parameter under Json data
stream.
UNICODE messages can be sent either by converting message text into hexadecimal representation and inserting that content into
binary tag or by inserting unconverted UNICODE text into text tag. In case when youre inserting unconverted UNICODE text you have
to relay Content-Encoding:UTF-8 information in the header when submitting messages using HTTP POST. No matter which meth-
od you use to submit UNICODE messages you always have to set DataCoding=8 parameter.
appid If value is not received all DLR-s without appid will be sent when client send pull re-
quest with no appid specified. If value is received only DLR-s with given appid will be
delivered when client pulls reports for that appid.
drPushUrl* If value is not received or received value is nopush all DLR-s without pushurl will be
pushed to default URL set for your account. If value is received DLR is sent to the given
URL (sent as pushurl value), rather than to the default one set for your account.
nopush* If value is not received or received value is 0 all DLR-s with nopush=0 will be pushed,
as usual. If value is received and received value is 1 all DLR-s with nopush=1 will not
be pushed, and will be available for pull.
RECIPIENTS GSM Message destination address, must be in international format
without leading 0or +.
Example: 41793026727
GSM messageId=clientmsgID Registered delivery - messageID set by client. 11
Pushurl and nopush combinations: If pushurl value is not empty and nopush=0, DLR will be pushed. If pushurl value is not empty and no-
push=1, DLR will not be pushed.
Abbreviated 6
For example,
if you want to send a message with the originator (sender name) 12345 (note, no leading +),
you should indicate src-ton = 2 (national), src-npi = 1.
If you want to add the leading + in the originator,
you should use src-ton = 1 (international), src-npi = 1.
If you want to use the alphanumeric originator, please set src-ton = 5 (alphanumeric), src-npi = 0.
If you do not specify src-ton and src-npi parameters, your message will be sent with src-ton = 1
for numeric sender, and src-ton = 5 for alphanumeric sender.
After the Json request is initiated by the client, some response codes will be available. Variable parts of the Json structure are
marked black.
The return Json string format will be as follows, for successful request:
Reponse Reponse
Content-Length: 95 Content-Length: 95
Date: Mon, 01 Oct 2012 11:55:02 GMT Date: Mon, 01 Oct 2012 11:55:02 GMT
{results: [ {results: [
{status:0,messageid: {status:0,messageid: clientmsgID ,desti-
072101113352779063,destination:385951111111} nation:385951111111}
]} ]}
Unsuccessful requests:
Reponse Reponse
Content-Length: 79 Content-Length: 79
Date: Mon, 01 Oct 2012 11:55:02 GMT Date: Mon, 01 Oct 2012 11:55:02 GMT
{results: [ {results: [
{status:-13, {status:- 1,
messageid:,destination:000000000000} messageid:,destination:000000000000}
]} ]
Request
POST http://api.infobip.com/api/v3/sendsms/json
Host: api.infobip.com
Content-Type: application/json
Accept: */*
{
authentication: {
username: test,
password: test
},
messages: [
{
sender: Sender,
text: Hello,
recipients: [
{
gsm: 385951111111
}
]
}
]
}
Reponse
{results: [
{status:0,messageid:10210011344550330860,destination:385951111111}
]}
Request
POST http://api.infobip.com/api/v3/sendsms/json
Host: api.infobip.com
Content-Type: application/json
Accept: */*
{
authentication: {
username: test,
password: test
},
messages: [
{
sender: Sender,
text: Hello,
recipients: [
{
gsm: 385951111111
},
{
gsm: 385952222222
},
{
gsm: 385953333333
}
]
}
]
}
Reponse
Content-Length: 253
Date: Mon, 01 Oct 2012 12:07:36 GMT
{results: [
{status:0,messageid:092100115456775780,destination:385951111111},
{status:0,messageid:092100897063776982,destination:385952222222},
{status:0,messageid:092105545063777484,destination:385953333333}
]}
Request
POST http://api.infobip.com/api/v3/sendsms/json
Host: api.infobip.com
Content-Type: application/json
Accept: */*
{
authentication: {
username: test,
password: test
},
messages: [
{
sender: test,
text: hello,
recipients: [
{
gsm: 385951111111,
messageId: clientsmsgID
}
]
}
]
}
Reponse
Content-Length: 95
Date: Mon, 01 Oct 2012 11:55:02 GMT
{results: [
{status:0,messageid: clientmsgID ,destination:385951111111}
]}
Request
POST http://api.infobip.com/api/v3/sendsms/json
Host: api.infobip.com
Content-Type: application/json
Accept: */*
{
authentication: {
username: test,
password: test
},
messages: [
{
sender: test,
text: hello,
sendDateTime: 0d0h10m,
recipients: [
{
gsm: 385951111111
}
]
}
]
}
Request
POST http://api.infobip.com/api/v3/sendsms/json
Host: api.infobip.com
Content-Type: application/json
Accept: */*
{
authentication: {
username: test,
password: test
},
messages: [
{
sender: test,
text: longtestsmsis very loooooooooooooooooooonglongtestsmsis very
loooooooooooooooooooonglongtestsmsis very loooooooooooooooooooonglongtestsmsis very
loooooooooooooooooooonglongtestsmsis very loooooooooooooooooooong end,
type: longSMS,
recipients: [
{
gsm: 385951111111
}
]
}
]
}
Request
POST http://api.infobip.com/api/v3/sendsms/json
Host: api.infobip.com
Content-Type: application/json
Accept: */*
{
authentication: {
username: test,
password: test
},
messages: [
{
sender: test,
text: ,
datacoding: 8,
recipients: [
{
gsm: 385951111111
}
]
}
]
}
Request
POST http://api.infobip.com/api/v3/sendsms/json
Host: api.infobip.com
Content-Type: application/json
Accept: */*
{
authentication: {
username: test,
password: test
},
messages: [
{
sender: test,
text: hello,
datacoding: 240,
recipients: [
{
gsm: 385951111111
}
]
}
]
}
http://api.infobip.com/api/v3/sendsms/plain?user=test&password=test&sender=Friend&bina-
ry=06050400010241424344&GSM=38598111111&esmclass=64
UNICODE messages can be sent either by converting message text into hexadecimal representation and inserting that content into Binary
tag or by inserting unconverted UNICODE text into SMSText tag. In case when youre inserting unconverted UNICODE text you have to use en-
coding optional parameter, Please refer to Table 5 for more information. No matter which method you use to submit UNICODE messages you
always have to set DataCoding=8 parameter.
PARAMETER DESCRIPTION
user Username
password Password
sender Message sender name
Alphanumeric sender: max. length 11 characters
Numeric sender: max. length 14 characters
SMSText Message text (160 characters)
GSM Recipient GSM number in international format (38598xxxx, 38591xxxxx, ...)
IsFlash Flash message - displays directly on handset screen.
Optional parameter: default value = false
0 false
1 - true
Type Optional parameter:
For WAP bookmarks set to type=bookmark,
for concatenated (long) SMS set type=LongSMS
and for notification SMS set type=nSMS
Bookmark The WAP URL link
DataCoding Data-coding parameter . Optional parameter, default value = 0
Esmclass Esm_class parameter . Optional parameter, default value = 0
Binary Binary content, optional parameter Format same as in XML <binary> parameter
Srcton Source-ton, please check XML parameter description
Srcnpi Source-npi, please check XML parameter description
Destton Destination-ton, please check XML parameter description
Destnpi Destination-npi, please check XML parameter description
ValidityPeriod ValidityPeriod pattern: HH:mm
Validity period longer then 48h is not supported (it will be automatically set to 48h in that case).
sendDateTime Used for scheduled SMS (SMS not sent immediately but at scheduled time).
4d3h2m1s means that message will be sent 4 days, 3 hours, 2 minutes and 1 second from now. Youre allowed to use any
combination and leave out unnecessary variables.
encoding Information about content encoding is relayed in the header.
For Firefox / Windows relay encoding=windows-1250
For Chrome / Linux relay encoding=UTF-8
appid If value is not received all DLR-s without appid will be sent when client send pull request with no appid specified. If value is
received only DLR-s with given appid will be delivered when client pulls reports for that appid.
pushurl* If value is not received or received value is nopush all DLR-s without pushurl will be pushed to default URL set for your
account. If value is received DLR is sent to the given URL (sent as pushurl value), rather than to the default one set for your
account.
nopush* If value is not received or received value is 0 all DLR-s with nopush=0 will be pushed, as usual. If value is received and
received value is 1 all DLR-s with nopush=1 will not be pushed, and will be available for pull.
Pushurl and nopush combinations: If pushurl value is not empty and nopush=0, DLR will be pushed. If pushurl value is not empty and nopush=1,
DLR will not be pushed.
Error responses returned on the HTTP request, messages will not be accepted by Infobip platform. Below table illustrates possible error responses
and their meaning.
With this API method you can collect sent SMS delivery reports. As soon as delivery reports for sent messages are received in the Infobip system,
they will be forwarded to you as an XML or Json formatted string.
If you used the POST sending method with Json data formatted with customized message id method, each delivery report will have the same mes-
sageId attribute as the message for which it is being sent (for details see previous chapter). If you used the POST method with Json data formatted
without customized messageid, the messageId attribute of collected delivery reports will be generated by the Infobip system.
ATTRIBUTE DESCRIPTION
id Clients message ID
sentdate Date/time when message was submitted from the client to the Infobip system. (format: yyyy/m/d hh:mm:ss)
donedate Date/time when SMSC notified the Infobip system of the delivery report (format: yyyy/m/d hh:mm:ss)
status NOT_SENT The message is queued in the Infobip system but cannot be submitted
to SMSC (possible reason: SMSC connection is down)
SENT The message was sent over a route that does not support delivery reports
NOT_DELIVERED The message could not be delivered
DELIVERED The message was successfully delivered to the recipient
NOT_ALLOWED The client has no authorization to send to the specified network
(the message will not be charged)
INVALID_DESTINATION_ADDRESS Invalid/incorrect GSM recipient
INVALID_SOURCE_ADDRESS You have specified incorrect/invalid/not allowed source address
(sender name)
ROUTE_NOT_AVAILABLE You are trying to use routing that is not available for your account
NOT_ENOUGH_CREDITS There are no available credits on your account to send the message
REJECTED Message has been rejected, reasons ma y vary
INVALID_MESSAGE_FORMAT Your message has invalid format
To be able to collect delivery reports you will need to set the delivery report URL in My Account page, under Infobip related contacts section in Status
Report URL field after successfully logging in to our Customer Area (https://customer.infobip.com).
If your delivery report URL is unavailable for any reason, forward attempts will be made according to table shown below. If your URL is not available
for the entire time, delivery reports will be lost.
RETRY
INTERVAL CUMULATIVE
NUMBER
0 01min 00:01h
1 02min 00:03h
2 05min 00:08h
3 10min 00:18h
<DeliveryReport>
.....
</DeliveryReport>
<?php
$postData = file_get_contents(php://input);
// extract XML structure from it using PHPs DOMDocument Document Object Model parser
$dom->loadXML($postData);
$reports = $xPath->query(/DeliveryReport/message);
?>
Unlike Push method, while using this method, you are calling one of the access point URLs illustrated below. This method returns the delivery report
in the XML format. Delivery reports can be Pulled only once, any consequent attempt shall result in NO_DATA response.
The URL to get delivery reports over HTTP GET method is:
Parameters:
++ user
++ password
++ messageid - optional, for requesting specific delivery reports possibility of requesting several by separating
the value with comma (,)
Return values:
++ 5 - invalid username and/or password
++ 10 - missing username
++ 11 - missing password
Example of delivery reports for SMS messages sent using Json POST, formatted with either customized messageid or Infobip generated messageid
(examples in PHP scripting language in previous chapter) and collected by this method:
Customized messageId
<DeliveryReport>
Infobip generated
<DeliveryReport>
</DeliveryReport>
HTTP GET or HTTP POST can be used to send a NUMBER CONTEXT request to our system. HTTP requests should be sent to the following URL:
NAME DESCRIPTION
user Your Infobip SMPP username
pass Your Infobip SMPP password
destinations addresses separated by ;
Example: 38598303174;38598111111;49170111222
++ One row will contain exactly one piece of destination data. Destination data (destination address, status, mes-
sageId)
will be separated by ;. MessageId may contain characters 0-9, A-F, and .
OK
123456;OK;121c0a6b752-1-92
23423423232;OK;121c0a6b752-1-93
230498239048230;FAILED;
2343223;OK;121c0a6b752-1-94 sdfsd;FAILED;
23422342342;OK;121c0a6b752-1-95
234234;OK;121c0a6b752-1-96
The destinations in our response will be exactly in the same order as you submitted them.
You will also receive the delivery report over HTTP at a later time.
We will send report for at most 100 messages in One HTTP request has a maximum capacity of delivery reports
for 100 messages. Our HTTP request will contain POST variable dlr in the following format:
dlr={destination:3859811111111,id:13a54ca0ece-fc84-bed,stat:UNDELIV,IMSI:,MSC:,er-
r:1153,mccmnc:21901,ppm:100,onp:98,ocp:385,is_ported:false,rnp:,rcp:,is_
roaming:false,pnp:,pcp:}
dlr={destination:385997046253,id:13a54cf9484-fc84-1237,stat:DELIVRD,IMSI:219019900073678
,MSC:3859804,err:0,mccmnc:21901,ppm:100,onp:99,ocp:385,is_ported:false,rn-
p:98,rcp:385,is_roaming:false,pnp:97,pcp:385}
Each destination address will be in a single row, with rows separated by a new-line (\n), with a maximum of 100 rows (100 delivery reports) per
request. If any parameter is missing for any reason (request failed etc), there will be an empty field.
Amount of parameters received depends on the Number Context package. Packages are agreed with the account managers.
This method gives you the ability to make a synchronous Number Context request over HTTP. Number Context response is returned immediately
thus eliminating the need for the call back server. If there is a system problem, the FAILED string is returned.
Synchronous Number Context request over HTTP works only for one destination per request. HTTP GET and HTTP POST methods
can be used to send requests, which should be sent to the following URL:
Table 10 Parameters
NAME DESCRIPTION
user Your Infobip SMPP username (required)
pass Your Infobip SMPP password (required)
destination Phone number (required)
output Desired output, supported values are (optional):
xml: values are formatted as xml
json: values are formatted as json
If no output parameter is specified, comma- based formatting will be used
Response parameters: 1
Request:
http://api.infobip.com/api/hlr/sync?user=test&pass=test&destination=38598xxxx&output=json
Output:
{destination:385997046253,id:13a54e79b51-fc84-1724,stat:DELIVRD,IMSI:219019900211811,MS
C:3859804,err:0,mccmnc:21901,ppm:100,onp:99,ocp:385,is_ported:false,rn-
p:98,rcp:385,is_roaming:false,pnp:97,pcp:385}
Example (XML):
Request:
http://api.infobip.com/api/hlr/sync?user=test&pass=test&destination=38598xxxx&output=xml
Output:
<hlr>
<destination>38598xxxxxxx</destination>
<id>12a1d3981ac-1-1e</id>
<stat>DELIVRD</stat>
<IMSI>219011000020098</IMSI>
<MSC>38598040004</MSC>
<err>0</err>
<hlr>3859812007</hlr>
<orn>T-Mobile HR</orn>
<pon>T-Mobile HR</pon>
<ron>T-Mobile HR</ron>
<roc>HR</roc>
<mccmnc>21901</mccmnc>
<rcn>Croatia</rcn>
<ppm>100</ppm>
<onp>98</onp>
<ocn>Croatia</ocn>
<occ>HR</occ>
<ocp>385</ocp>
<is_ported>false</is_ported>
<rnp>98</rnp>
<rcp>385</rcp>
<num_ok>true</num_ok>
</hlr>
Infobip provides different ways for collecting SMS messages sent by GSM phones of your customers. For example, we can host your GSM SIM cards
at our GSM modem farm. When your customer sends an SMS message to that SIM, it arrives in our system. For more detailed specifications and
options, please contact our sales department.
After a message has arrived in our system, it can be forwarded to your server using an HTTP GET request by default, POST is available however it is
done on request basis. You have to provide a URL we should use. It means that you have to prepare such a URL on your web server.
We are able to forward the following parameters:
Table 9 Parameters
PARAMETER DESCRIPTION
Sender SMS message sender (GSM phone number)
Receiver Recipient number (if available)
Text Received message text
Bin Binary content of received message
Datetime Date and time of message reception
MessageId Identifier for specific MO message
Datacoding Message data coding
Esmclass ESM-class parameter of the message
output Desired output, supported values are (optional):
xml: values are formatted as xml
json: values are formatted as json
Receiver parameter will be set to the value of your GSM SIM mobile number (if you are using SIM hosting to receive messages).
In case you provided URL with both bin and text parameters, take care of the following: if datacoding parameter is 0, then we will forward to you
only message text, bin parameter will be set to (empty string). If datacoding is not 0 (example 8 = Unicode message), then we will send you
binary content only, parameter text will be set to (empty string).
However, if you do not support both parameters (bin and text) in URL (of course, you should use at least one of them, in order to receive message
content), we will provide everything, no matter what is in datacoding parameter. We use send only binary or only text logic to make HTTP GET re-
quests as short as possible.
then our system will make the following HTTP request (after receiving message from +38598123123 that says
ABC):
http://some.server.com/incoming_sms.php?who=38598123123&what=ABC
Note that there is no leading + in sender field. In case you want to use binary parameter instead of text, you
should provide the following URL:
http://some.server.com/incoming_sms.php?who=%sender%&what=%bin%
The URL to get incoming messages for your 2-way event over HTTP using PULL method is:
NAME DESCRIPTION
username Your username
password Your password
limit Maximum number of messages to fetch, default is 0
which means all
output Defines output format which can be xml or json, de-
fault is xml.
3 SMPP
The \connection between the application and the Infobip SMPP server is SMPP version 3.4 (version 3.3 is not supported).
NAME DESCRIPTION
system_id Provided for each client
password Provided for each client
IP address Primary connection point: smpp3.infobip.com
Secondary connection point: smpp1.infobip.com
SSL Connection point : smpp2.infobip.com
port 8888 (primary and secondary) / 8887 (ssl)
timeout (keep alive or msg) 30 sec
system_type (optional) <r:route_code>
You are allowed to bind as transmitter, receiver or transceiver. In order to receive delivery reports,
you must bind as transceiver or receiver.
PDUs supported:
bind_transmitter, bind_receiver, bind_transceiver, unbind, submit_sm, deliver_sm, enquire_link
DR format:
id:<message_id> sub:<message_sub> dlvrd:<message_dlvrd>
submit date:<message_submit_date> done date:<message_done_date>
stat:<message_stat> err:<message_err>
Text encoding
Please use GSM7 (IA5) as default encoding when sending messages.
If you are using ISO-8859-1 (Latin1) please let us know so that we can set up your account properly.
Scheduled delivery
Scheduled delivery is supported over SMPP protocol using the relative time format. For example, 070605040302100R would mean that message
will be delivered 7 years, 6 months, 5 days, 4 hours, 3 minutes, 2 seconds and 1 tenth of second from now.
Using Infobip SMPP account, it is possible to request Number Context data (IMSI). In order to use Number Context, you can use your default
system_id and password, setting system_type = HLR (without quotation marks) in Bind PDU.
SubmitSM PDU is used for submitting the Number Context request, having destAddress parameter set to the required destination address. All other
parameters will be ignored (srcAddress, TON/NPI, etc). Infobip Number Context subsystem will respond using a regular SubmitSMResp, containing
message-id reference.
Once the Number Context request is being finalized on the Infobip system, you will receive DeliverSM PDU, containing the IMSI for the required de-
stAddress, or error code in case of failure. DeliverSM will contain short message data with our regular delivery report, together with IMSI:xxxxxxxxx
part (containing IMSI), serving MSC and a number of optional info fields depending
on your package.
Examples
In case Number Context request was successful, DeliverSM will be as follows (IMSI 21910110053751):
addr: 0 0 38591xxxxxxx
addr: 0 0 0000000000
msg: id:40072910491427628 sub:001 dlvrd:001 submit date:1007291049 done date:1007291049 stat:DELIVRD err:000
IMSI:219101100935850 MSC:38591016 HLR:38591xxxxxxx ORN:VipNet PON:VipNet RON:VipNet ROC:HR MCCMNC:21910
opt: (oct: (tlv: 1059) 030000) (byte: (tlv: 1063) 2) (str: (tlv: 30) 40072910491427628) (str: (tlv: 5129)
38591xxxxxxx) (str: (tlv: 5138) VipNet) (str: (tlv: 5139) VipNet) (str: (tlv: 5140) VipNet) (str: (tlv:
5141) Croatia ) (str: (tlv: 5143) HR) (str: (tlv: 5142) 21910) (int: (tlv: 5144) 1) (str: (tlv: 5145) 91)
(str: (tlv: 5152) 385) (int: (tlv: 5153) 1) (str: (tlv: 5154) Croatia ) (str: (tlv: 5155) HR) (str: (tlv:
5156) 385) (int: (tlv: 5157) 1) ) (extraopt: (oct: (tlv: 5123) 323139313031313030393335383530) (oct: (tlv:
5126) 3338353931303136) )
addr: 0 0 385915369423
addr: 0 0 0000000000
msg: id:40072910491419819 sub:001 dlvrd:001 submit date:1007291049 done date:1007291049 stat:UNDELIV err:001
IMSI: MSC: ORN:VipNet MCCMNC:
opt: (oct: (tlv: 1059) 030001) (byte: (tlv: 1063) 5) (str: (tlv: 30) 40072910491419819) (str: (tlv: 5138)
VipNet) (str: (tlv: 5142) ) (int: (tlv: 5144) 1) (int: (tlv: 5153) 0) (str: (tlv: 5154) Croatia ) (str:
(tlv: 5155) HR) (str: (tlv: 5156) 385) (int: (tlv: 5157) 1) )
You can use your Infobip SMPP account to send Flash notifications. Such notifications are immediately displayed on your mobile phone screen upon
arrival and arent stored in the memory of such device. In order to use Flash notifications, you can use your default system_id and password, setting
system_type = NSMS (without quotation marks) in Bind PDU.
Please note that long SMS feature is not supported for Flash notifications.
List of the delivery error codes, returned by Infobip platform, in the delivery reports, for both SMPP and HTTP protocols. These error codes illustrate
reason of non-delivery for a specific SMS.
Supported values by Infobip platform, to facilitate specific message creation type. It is important to note that values marked with asterisk are
destination dependant, therefore, please check with your respective account manager, if the feature is supported for the chosen destination.
VALUES DESCRIPTION
1 GSM7
3 ISO 8859 - 1
4 Binary
8 Unicode
24 Unicode Flash*
240 Flash*
245 Wap Push*
Received as an response for Submit_SM, on special events, illustrated in the table below.
Sending USA short code MT messages requires special parameters to be sent over API. If parameters are not submitted, we cannot guarantee suc-
cessful delivery of messages.
String parameter that defines the Campaign to which the message content belongs. CampaignId is mandatory for all standard MT messages.
CampaignId is unique for each provisioned campaign on your short code and it is provided to you by your account manager.
Information on specific requirements for using such setup can be obtained from dedicated account manager
SMS on Wikipedia
(Footnotes)
www.infobip.com
[email protected]