BILL webhook API notification rules

Event notifications from the BILL webhook API follow a set of rules.

Design	Description
Notification URL	The notification URL is the location where you receive event notifications. The URL that you provide must be HTTPS. Note: When you are testing with BILL webhooks, you can use an online service for setting up a notification URL. For example, public.requestbin.com.
All notifications are organization-specific	BILL sends you event notifications only for the BILL organization used to set up a subscription. When you set up a subscription, the `organizationId` in the API response represents the BILL organization for which your subscription is created. See Working with BILL webhooks for more information.
Event notification `id`	BILL sends each event notification with a unique event `id`. Your integration must save event `id` value to avoid processing any duplicate notifications.
JSON escaped payload	When BILL sends you an event notification, the `payload` is JSON-escaped and is presented as a string. Ensure that your integration handles JSON escaped payloads for notifications. See Working with BILL webhooks for more information about a sample payload.
Order of notifications	In case notifications are sent out of order, organize the notifications based on the timestamp of each notification.
Notification retries	When BILL does not receive a HTTP 200 `statusCode` for an event notification within 10 seconds, the notification is considered a failure. When an event notification fails, BILL tries to send the notification again with exponential backoff. When BILL does not receive a HTTP 200 `statusCode` after resending a notification five times, BILL sends the notification in a Dead-Letter Queue (DLQ) and handles notification retries at a later time. To address any issues with notification retries, you can get the list of event notifications sent to you for a subscription with `GET /v3/events/subscription/{subscription_id}`.