Push notifications are sent out from the Wiraya backend retroactively several times per minute, and can deliver data for events regarding incoming and outgoing SMSes and phone calls. Permissible protocols are HTTP and HTTPS, and self-signed certificates are accepted. 

Batched requests, basic access authentication, client certificates and customized headers are supported.

Customers may customize the push contents and URLs to contain any available metric. Requests can be sent as GET, or as POST with a customized JSON or XML body. Some metrics are available only for certain types of communications, while others are generic.

Available metrics:

{TYPE} the type of communication the push relates to (incoming/outgoing SMS/call)

{ID} unique ID for the SMS/call

{CID} unique customer ID the push is serving

{RID} unique ID of the recipient, if the communication involved a contact list

{PRID} project ID for the SMS or call

{RECIPIENT} the number that received the SMS or call

{SENDER} the number (or name) of the sender of the SMS or call

{STATUS} contains the delivery status of an outgoing SMS or call: for outgoing SMSes
the possible values are [DELIVERED, NOT_DELIVERED, NOT_WHITELISTED, OPTOUT, FAILURE, UNKNOWN, SPAM, TEST]; for outgoing calls they are [DELIVERED, NEXTATTEMPT, NOTREACHED, OPTOUT, INCORRECTNUMBER, SPAM, TEST]

{CONTENT} the full content of an outgoing SMS, or relevant payload of an incoming SMS

{SMS_PARTS} for outgoing SMS; the number of parts (SMSes) required to send the content

{SENT_UNIXTIME} Unix timestamp for when an outgoing SMS or outgoing call was sent, or when an incoming SMS was received

{SENT_DATETIME} as above, with format YYYY-MM-DD HH:MM:SS in UTC

{SENT_DATEISO} as above, with ISO 8601 format in UTC

{DONE_UNIXTIME} Unix timestamp for outgoing SMS delivery report, or when call ended

{DONE_DATETIME} as above, with format YYYY-MM-DD HH:MM:SS in UTC

{DONE_DATEISO} as above, with ISO 8601 format in UTC

{RECIPIENT_STATUS} for outgoing SMS; possible values are [EXISTS, DOESNOTEXIST, UNKNOWN, LANDLINENUMBER], reflecting the status of the receiving number, either through estimation or by operator confirmation, depending on the customer's account level

{1}..{99} the recipient's data fields, if the communication involved a contact list

{KEY_CHOICES} for outgoing calls; the series of key choices made by the callee, as CSV

{BULK} the full content of an incoming SMS

{IDENTIFIER} the identifier of an incoming SMS

{PREFIX} the prefix of an incoming SMS


Example URL using GET to transport metrics:

https://push.company.org/receiver.php?contact={RID}&id={ID}&to={RECIPIENT}&status={STATUS}


POST example using a JSON body to transport metrics:

{"id":{ID},"UUID":"{3}","unixtime":{DONE_UNIXTIME},"recipient status":"{RECIPIENT_STATUS}"}


Batched requests are supported when using POST, and the maximum number of events per request is configurable. Events will be delivered in an array with the name batch holding multiple items.

Example POST body:

{"id":{ID},"to":"{RECIPIENT}","when":"{SENT_DATEISO}"}


Resulting POST payload with a batch size of 3:

{
       "batch":
       [
           {
               "id":1000007,
               "to":"46710000123",
               "when":"2019-01-10T13:00:00Z"
           },
           {
               "id":1000088,
               "to":"46710000456",
               "when":"2019-01-10T13:00:04Z"
           },
           {
               "id":1000105,
               "to":"46710000789",
               "when":"2019-01-10T13:00:11Z"
           }
       ]
   }


Customers are recommended to always request the ID of the pushed item, for referring back to Wiraya in case of problems with pushed data. Additionally, we recommend transporting your metrics by POST instead of GET to avoid potentially sensitive information ending up in unforeseen locations, f.e. in web server logs.

Our IP addresses push notifications may originate from (for whitelisting):
35.158.187.151
52.59.121.86
18.197.103.66

Did this answer your question?