Skip to main content

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:

MethodContent TypeComments
HTTP_POSTapplication/x-www-form-urlencoded
HTTP_POST_INSECUREapplication/x-www-form-urlencodedDoes not check for a valid SSL certificate on https endpoints
HTTP_JSONapplication/json

We will POST the parameters in the table below.

ParameterDescriptionExample
imeiThe unique IMEI of your RockBLOCK300234010753370
serialThe serial number of your RockBLOCK12345
momsnThe 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_timeThe date & time (always UTC) that the message was transmitted.21-10-31 10:41:50
iridium_latitudeThe approximate latitude of the RockBLOCK at the time it transmitted.52.3867
iridium_longitudeThe approximate longitude of the RockBLOCK at the time it transmitted.0.2938
iridium_cepAn estimate of the accuracy (in km) of the position information in the previous two fields.8
dataYour 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.