Success and failure
A 2xx response within 15 seconds is a success. Everything else is a failure. The 15 seconds include resolving the address.- A 3xx is a failure, because redirects aren’t followed.
- The response body isn’t used.
Retries
A failed event is sent up to 8 times in total, including the first attempt, at increasing intervals over about 24 hours. If the last attempt fails, the event is dropped.Handle duplicates
The same event ID can arrive more than once. Drop duplicates byid.
- A retry keeps the same
idand increasesattempt_number. - The body changes, so the signature differs per attempt.
- In rare cases, an event you already received can arrive again.
Checks before sending
These are checked right before each send. If any fails, the event is dropped regardless of attempts.- The subscription is on.
- The integration still exists.
- The database is still connected and the integration can read the document.
- For
comment.*events, Read comments is on.
See failures
Failed deliveries on the integration’s page shows the failure count and the last failure time. The count is per attempt, not per event, and doesn’t go down when a retry succeeds. There’s no list of failed events and no button to resend them.Automatic pause
If failures continue, a subscription can be paused. Changes made while it’s paused aren’t sent, even after you resume. When it pauses, events waiting to be sent are dropped, and the app shows Paused because the receiver kept failing. Select Resume to send changes made from then on.Catch up on missed changes
Changes missed through a pause or through failed attempts can’t be received again. Catch up with a query that reads only rows edited after the last time you processed.last_edited_time is truncated to the minute, so start 1 minute before your last processed time. Trashed rows don’t appear in this query. Read them separately with in_trash: true.