Receiving MO messages via HTTP Webhook
This is the preferred method for delivery to your application as it provides guaranteed delivery.
You must first configure the URL(s) of your application, which can be done by logging in to your RockBLOCK account.
When a message is sent by your RockBLOCK, we will open an HTTP connection to your application URL.
Depending on which format you select for the delivery address in the RockBLOCK Management System the content type will be one of the following:
Method | Content Type | Comments |
---|---|---|
HTTP_POST | application/x-www-form-urlencoded | |
HTTP_POST_INSECURE | application/x-www-form-urlencoded | Does not check for a valid SSL certificate on https endpoints |
HTTP_JSON | application/json |
We will POST the parameters in the table below.
Parameter | Description | Example |
---|---|---|
imei | The unique IMEI of your RockBLOCK | 300234010753370 |
serial | The serial number of your RockBLOCK | 12345 |
momsn | The Message Sequence Number set by RockBLOCK when the message was sent from the device to the Iridium Gateway. The value is an integer in the range 0 to 65,535 and is incremented each time a transmit session is successfully completed from the device to the Iridium Gateway. It is a wrap around counter which will increment to 0 after reaching 65535. | 12345 |
transmit_time | The date & time (always UTC) that the message was transmitted. | 21-10-31 10:41:50 |
iridium_latitude | The approximate latitude of the RockBLOCK at the time it transmitted. | 52.3867 |
iridium_longitude | The approximate longitude of the RockBLOCK at the time it transmitted. | 0.2938 |
iridium_cep | An estimate of the accuracy (in km) of the position information in the previous two fields. | 8 |
data | Your message, hex-encoded. | 48656c6c6f20576f 726c6420526f636b 424c4f434b |
Your application must respond promptly (within 3 seconds) with an HTTP status 200, to indicate that you have successfully handled the message.
We strongly advise that you limit the amount of processing you do on the connection handling thread. It is important that you respond quickly to free up resources.
Any other response will cause the message delivery to remain in our delivery queue, and another attempt will be made after 1 minute. After each failure, the backoff period is doubled. After 14 attempts (almost 6 days) the message will be marked as failed and removed from the queue.