Read on how to deal with our webhooks

After the Subscription API has been set up, webhooks are ready to use. Webhooks will be fired from our end when any listed event is triggered. We will trigger a POST request to the URL provided on the Subscription API.

Webhook Request

When an event is created on our end we POST following details as part of the webhook to the URL mentioned on Subscription API.

HEADER x-raas-webhook-signature d2b730bba0de481fb079fff1478435231a9b410005ee599e67428930b7f340c3 x-raas-event : transaction_completed POST PAYLOAD




We generate a signature using the secret mentioned on the Subscription API.


Event Name


Webhook unique identifier


Event name. User as that of header x-raas-event


Id of the resource for which the event was generated. If transaction_completed is triggered the resource_id will be transaction id. You can fetch the particular resource using the resource_id.


If user related resources are triggered as part of an event then user_id will be sent as part of the payload.


Subscription Id for which this event was generated.


In case of a cip tag status event, this contains a list of cip tags for which the status has been updated.


Timestamp when the webhook is posted.

Responding to Webhooks

When you receive the webhook events, you can respond back with the following HTTP Status after the processing has been completed on your end.

HTTP Status


2xx HTTP

This will acknowledge that the webhooks event was successfully captured and no further webhooks event will be generated from our end.

409 Conflict

If this HTTP code is returned from your end, we will trigger the webhooks on a fixed interval until a success response is received from your end.

Rest of HTTP Codes

Any other response during webhooks response including 3xx codes will be marked as failure. Consecutive Webhooks Failures will pause the subscriptions for which the webhooks failed. You will have to update the paused subscriptions if you want to receive further webhooks on that subscription.

Last updated