--- updatedAt: 2026-08-16T10:54:34.000Z agentTools: projectIndex: https://developers.deliverect.com/v1.1-restaurants/llms.txt --- # How POS Order Failover works ## Overview To deal with potential order injection failures, we have a retry policy that uses an exponential backoff with a maximum of 5 retries. This means we may try the connection request up to six times (one initial attempt plus five retries) before marking the order as failed. ### Retry Criteria Retries are attempted only under the following failure conditions; * Inability to establish a network connection within 3 seconds. * Receipt of an HTTP `502`, `503`, or `504` server-error response. ### Retry Interval Retries will use an exponential backoff factor of 2. After the first failed attempt, subsequent retries are delayed using the schedule shown below, beginning with a 10 second delay The total potential backoff wait time would then be 310 seconds (assuming failures occur immediately)\ If each connection attempt awaits the full 3 seconds, the total retry duration increases to 328 seconds | Retry attempt | Retry delay | Time since first attempt | | :------------ | :---------- | :----------------------- | | 1 | 10s | 10s | | 2 | 20s | 30s | | 3 | 40s | 1m 10s | | 4 | 80s | 2m 30s | | 5 | 160s | 5m 20s | ### Retry Workflow The diagram below illustrates the order-injection workflow for POS integrators, including failover handling and the retry mechanism Failover Flow See also the documentation on [Order Webhooks](https://developers.deliverect.com/reference/post-orders-webhook)