These are the webhooks that Bringg may send you:

The last 2 may not be relevant to your integration but the first 3 need to be implemented.


Properly signed SSL Certificates

Webhook endpoints using HTTPS need to have properly signed SSL certificates.
Bringg does NOT accept self-signed certificates (for example, in your staging environments) because of the threat of Man-in-the-Middle (MITM) attacks.



All the webhooks are sent using POST.



All webhooks should have a 200 response if successful. If Bringg does not receive a 200 response, we will consider it as an error.

Only the Delivery Created webhook requires you to add something in the response: "success:true" and the "delivery_id" OR success:false. See https://developers.bringg.com/docs/delivery-created-webhook for more information.

Storing / Mapping Bringg IDs

From the "Delivery Created" webhook, you will need to store/map the following Bringg IDs alongside your Delivery item. The API calls you will make reference these unique IDs:

  • Order ID (mandatory)
  • Way point ID (this is useful but optional)

Way Point = Stop along the route. Usually there are 2 way points for every order :

  • Pickup/Store/Warehouse
  • Dropoff/Customer

API Key Sent in the Webhook Header

Bringg will pass an API key in the header of the webhooks. This will allow you to identify these webhooks as coming from a particular Bringg merchant.

It will also allow you to authenticate that the webhook is coming from Bringg.

You will find the specific API key for each merchant on the Registered Merchants page in your Sandbox.


Authorization Header

Please note that the API key will be sent in the Authorization header of the webhook.
It will NOT be sent in the x-api-key header.

Retrying Webhooks

Bringg will retry sending webhooks if we receive the following HTTP status codes:

  • 500 - Internal Server Error
  • 502 - Bad Gateway
  • 503 - Service Unavailable
  • 504 - Gateway Timeout

Webhook sending will be retried 3 times, with a 1 minute delay between each retry.