Errors
The Eats APIs use HTTP response codes to communicate errors. A list of common errors encountered on the platform is listed below. As a general rule of thumb, a 4xx error is an issue on the client side, and a 5xx is an error on the Uber side.
¶ HTTP Response Codes
| Error | Code | Message | Transient | Description |
|---|---|---|---|---|
| 400 | validation_failed | Invalid request | No | The input failed validation. This may happen if any of the input fields are not the correct type, or required fields are missing. |
| 403 | user_not_allowed | User not allowed to access the store | No | Current user is not allowed to access this store. |
| 403 | user_not_allowed | User not allowed to access the order | No | Current user is not allowed to access this order. |
| 403 | resource_update_not_allowed | Updating online_status of this store is not allowed | No | The store online status strategy is not external. |
| 403 | resource_update_not_allowed | Updating auto_accept_enabled of this store is not allowed | No | Auto-accept is only configurable by Uber Eats. This setting cannot be updated by API. |
| 404 | resource_not_found | Store not found | No | The provided store id does not exist. |
| 404 | resource_not_found | Order not found | No | The provided order id does not exist. |
| 409 | resource_status_conflict | Order status conflict | No | This usually means you have tried to accept / deny an order that has already been accepted or denied. |
| 500 | internal_server_error | Internal Server Error | No | Indicates an internal error on the Uber side. |
| 503 | service_unavailable | Service Unavailable | Yes | Usually indicates some connectivity issues internal to Uber. |
¶ Error Handling
Communicating with remote services or resources, especially over the Internet can be subject to transient failures. A transient failure can include, but is not limited to the following:
- A temporary loss in network connectivity.
- A temporary unavailability of a service or data.
- Service Timeouts.
Failures of this type are not typically long-lasting and if the action that triggered the failure is retried after a reasonable period of time, the subsequent call is likely to succeed.
By default, the Uber API will not retry a failed request. The HTTP Response Codes may be useful in determining whether a retry is appropriate and how long to wait before attempting the retry.
The list below outlines several strategies that can be performed on transient failures:
- Exponential Backoff (Recommended): Wait a short time before retrying the request, then exponentially increasing the time between each subsequent retry.
- Regular Intervals: Wait the same amount of time between each retry operation
- Immediate Retry: Retry the operation immediately. It should be noted that an immediate retry should only be attempted once, and if additional retries are required that one of the above strategies should be preferred.
An operation that results in a fatal error should not be retried as the operation is unlikely to succeed with subsequent attempts.
Retries that are too aggressive can have an adverse effect on the remote service or resource and may present the system from recovering and can result in requests being blocked or throttled.