Open In Colab
GitHub
Example configurations to receive requests
Create webhook
Webhook v2 setup
You can create a v2 webhook through the Labelbox UI. The v2 webhook mimics the export payload.Webhook v1 setup
As shown below, you can create a v1 webhook with the Python SDK or the Labelbox UI, which is similar to v2 webhooks.Get webhooks
Update webhook
Delete webhook
Sample response
v2
v1
Delivery retries
When your endpoint does not answer a delivery with a2xx status within 30 seconds, Labelbox sends it again 10 seconds, 30 seconds, and 90 seconds after the previous attempt: up to 3 retries, so at most 4 attempts. An error status, a timeout, and a failed connection all count as a failed attempt. After the fourth failed attempt Labelbox stops, and you can find the event in the webhook events list.
A retry is the same request as the first attempt: the same body, the same X-Labelbox-Id and X-Labelbox-Event, and the same X-Hub-Signature and X-Hub-Signature-256. A retry also carries an X-Labelbox-Delivery-Attempt header with the attempt number, 2 to 4. The first attempt does not send this header.
- Deduplicate by
X-Labelbox-Id. If your endpoint processed an event but answered too late or with an error, it receives the event again. Skip the IDs you have already processed. - Answer quickly. Return a
2xxas soon as you have stored the event and do slow work afterwards, so that a delivery is not retried while you are still processing it. - Retries stop with the webhook. If the webhook is deactivated or deleted, the remaining retries of its events are not sent.
- Best effort. A retry can occasionally be lost, for example while Labelbox deploys an update. The webhook events list has every event, whatever happened to its deliveries.
Delivery retries are rolling out gradually. Until they are on for your organization, Labelbox sends each event once, and every event in the webhook events list has a single attempt.
Catch up on missed events
If your endpoint was down or kept returning errors, it may have missed events, even after delivery retries. To find them, list your organization’s webhook events from the last 30 days, starting after the last event your endpoint processed, and process the ones you missed. The list shows what Labelbox sent: every event, with the payload and each attempt to deliver it, with the HTTP status your endpoint returned. Reading it does not send anything again.Before you start
You need:- A Labelbox API key.
- Permission to view webhooks in your organization, as the Admin and Read-only Admin roles have. Without it, the request is refused with
403. - The ID of the last event you processed. It is the
X-Labelbox-Idheader of that delivery, so keep it with each event you process.
GET request, authenticated with your API key as a bearer token:
List events
Get the events sent to one webhook after an event you processed:cURL
data, oldest first:
Parameters
Any other parameter, or a parameter given more than once, is refused with
400.
Event fields
Each webhook gets its own delivery of an event, with its own ID. If your organization has more than one webhook for the same events, filter by
webhook_id to list only the deliveries to your endpoint.
Page through the events
Events come in the order of their IDs, which is the order they were sent. Request pages untilhas_more is false, passing the next_cursor of each page as the starting_after of the next, with the same filters. next_cursor is null on the last page.
With event_type, project_id, created_after, or created_before, one request examines at most 5,000 events. If it reaches that limit before it fills the page, it returns the events it found, possibly none, with has_more true. next_cursor is then the last event it examined, which may not be in data. Keep paging: an empty page does not mean you have reached the end.
This example processes every event sent to your webhook after the last one you processed, and returns the ID to start from next time:
Python
Data freshness and limits
- Five minutes behind. An event is listed about five minutes after it was sent. Events from the last five minutes are not listed yet, and an event ID cannot be used as
starting_afteruntil it is five minutes old. - Slow endpoints. An event is recorded only after your endpoint responds. If your endpoint took longer than five minutes to respond, the event can be listed after you have already paged past its ID.
- 30 days. Only events from the last 30 days are listed. An older event ID is refused with
400: start again withcreated_afterinstead.