Skip to main content

Open In Colab

GitHub

See Webhooks guide page for details on how to use webhooks to receive notifications from activities in Labelbox.

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 a 2xx 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 2xx as 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-Id header of that delivery, so keep it with each event you process.
The endpoint is a 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
The response has the events in 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 until has_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
Your endpoint may also have received some of these events. Skip the IDs you have already processed.

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_after until 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 with created_after instead.

Errors