Responding
Answer with any 2xx status as soon as you have stored the event. We don't read the response body. Do slow processing afterwards: we wait 15 seconds by default.
Retries
- Anything else, including a timeout, a redirect or a connection error, fails the attempt, and we try again after 2, 4, 8, 16 and 32 minutes, then every 60 minutes until it succeeds.
- After 20 failed attempts in a row across a subscription's deliveries, we disable the subscription and stop sending to it. Fix the endpoint, then activate the subscription again in the developer portal.
- While a subscription is paused or disabled, new events are not sent to it and failed deliveries are not retried. Activating it again resumes the retries, but doesn't send the events from that time: use Resend events for that. See Troubleshooting.
Alert emails
We email when a subscription's deliveries start failing (3 failures in a row), when it is disabled, and when it recovers. These emails go to:
- Your Integration Managers. Each one chooses on their developer portal profile whether they get alerts, and for which subscriptions.
- The subscription's alert emails. Add addresses that don't sign in to the portal, such as a support mailbox, on the subscription. Each new address is told it was added, and every alert has a link to stop them.
Send test alert on a subscription checks that the emails reach the right people.
Duplicates and ordering
- Delivery is at least once: you may receive the same event more than once, for example after a timeout, a retry or a replay. Use
X-Syncor-Event-IdorIdempotency-Keyto ignore events you have already processed. - Order is not guaranteed across events, because each one is retried on its own. Use the document numbers and timestamps in the body. Catalog batch parts are the exception: they arrive strictly in order.