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.
POST HTTP Method
All the webhooks are sent using POST.
Responses
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 thex-api-keyheader.
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.