Integration Error Handling

During integration, our system has internal alarms and retries on multiple points of communication to ensure a consistent and positive customer experience. However, when errors do occur, they may require different solutions depending on the type of error. For example, errors in 5XX (500 code range), which are typically server-side issues, can be resolved with a simple retry. These errors include timeouts, internal server errors, and bad gateways. 4XX errors typically involve an issue with input parameters, body, or authentication. These may require a configuration update to resolve the issue, therefore, retries are not recommended.

API Request Retry Suggestions

The following are recommendations based on the request operation:

Operation	Description	Recommendation
POST /order	The createOrder request reaches out to multiple services and endpoints and has the heaviest request in the order life cycle with the most backend dependencies	Retries are encouraged. If the 29 second timeout (504 error code) is too long to wait, we encourage the client to implement their own timeout with 10 seconds being the most common. The 10 second value allows for a slower query to process without too long of a wait time.
PUT and DELETE /order/{_id}	All requests that edit an existing order.	Retries for 500 and 502 error codes are recommended. These errors typically occur before edits to the referenced order have been saved in the database. If the application is synchronous to the end user, thus having a heavy focus on the user experience, it is not recommended to perform retries on 504 error codes as the user has likely already waited 29 seconds. However, if the application performing the above requests is asynchronous to the end user and is initiated from some background process, it may be beneficial to implement retries to ensure that every attempt has been made to update the order successfully. An exception can be made for 504 error codes where the timeout is set to 10 seconds. Note A client-set 10 second timeout on order update requests runs the possibility of the backend Online Ordering function continuing its current operation, which could be the final order update to the database. If this happens, the retry has a greater possibility of failing because the previous request did in fact succeed. If an error is received with the retry, perform a GET operation on the order to review its current state based on the action that is being attempted. For example, if an attempt to add a payment fails with a client timeout and the subsequent retry fails, send a GET request on the order to confirm if the initial payment was added to the order in the `order.payment_status` field.
GET /order/{_id}	Get the order by its identifier	Retries are recommended

Operation

Description

Recommendation

POST /order

The createOrder request reaches out to multiple services and endpoints and has the heaviest request in the order life cycle with the most backend dependencies

Retries are encouraged. If the 29 second timeout (504 error code) is too long to wait, we encourage the client to implement their own timeout with 10 seconds being the most common. The 10 second value allows for a slower query to process without too long of a wait time.

PUT and DELETE /order/{_id}

All requests that edit an existing order.

Retries for 500 and 502 error codes are recommended. These errors typically occur before edits to the referenced order have been saved in the database.

If the application is synchronous to the end user, thus having a heavy focus on the user experience, it is not recommended to perform retries on 504 error codes as the user has likely already waited 29 seconds. However, if the application performing the above requests is asynchronous to the end user and is initiated from some background process, it may be beneficial to implement retries to ensure that every attempt has been made to update the order successfully.

An exception can be made for 504 error codes where the timeout is set to 10 seconds.

Note

A client-set 10 second timeout on order update requests runs the possibility of the backend Online Ordering function continuing its current operation, which could be the final order update to the database. If this happens, the retry has a greater possibility of failing because the previous request did in fact succeed.

If an error is received with the retry, perform a GET operation on the order to review its current state based on the action that is being attempted. For example, if an attempt to add a payment fails with a client timeout and the subsequent retry fails, send a GET request on the order to confirm if the initial payment was added to the order in the order.payment_status field.

GET /order/{_id}

Get the order by its identifier

Retries are recommended

Note

Performing at least one retry should resolve the issue in most cases. However, for non-timeout 5XX error codes, it is recommended performing up to three sequential retries before considering the request as unable to be completed.

Integration Error Handling

Note

Note

Search results