Batching. Changes that are processed together are sent in one call, with up to 500 changes per call. A quiet
project produces about one call per change; a busy one groups them.
No ordering guarantee. Calls can arrive out of order. Sort by changes[].timestamp if order matters.
At least once. A call can arrive more than once, also after a failure on our side; it then has the same
deliveryId. Deduplicate calls by deliveryId and changes by eventId, type and itemId or userId.
Answer fast. Respond with a 2xx status within 10 seconds and do the work afterwards. Redirects are not
followed, and the response body is ignored.
Retries.408, 429, 5xx, timeouts and network errors are retried 8 times over about 8 hours
(after 30 s, 1 min, 5 min, 15 min, 30 min, 1 h, 2 h and 4 h). Other 4xx answers are not retried.
Pending retries follow the webhook. Every retry uses the webhook's current URL, so fixing a broken URL lets
pending retries succeed. Deleting or disabling a webhook, or deleting its project, cancels its pending retries.
Automatic disable. After 20 failed deliveries in a row the webhook is disabled. Answering 410 Gone disables
it at once. The reason is shown in the webhook's status. Re-enable it with
POST /api/v2/projects/{projectId}/webhooks/{webhookId}/enable or by updating it.
Avoid loops. If your endpoint writes back to the project, ignore changes whose actorId is the user of your
API token.
Network. Only public internet addresses are called. URLs that resolve to private, loopback or link-local
addresses fail.
Imports. No calls are made while a project is being imported, migrated or deleted.