To maintain a great customer experience for merchant integrations utilizing Uber Eats Marketplace APIs, we require our partners to adhere to specific quality and performance standards.

These standards are subject to adjustment at any time and a failure to adhere to or meet these standards may result in temporarily or permanently revoked API access and/or removal or disabling of merchant stores.

¶ Quality Standards

Integration quality is essential to the Eats marketplace as it allows partners to take full advantage of the suite of Eats workflows and integration features and ensures Eaters have a great experience. As new workflows/features are amended or added, partners will be expected to support and incorporate these changes into their integrations.

The Uber API is constantly being worked on to add features, make improvements, and fix bugs. This means that you should expect changes to be introduced and documented. When a significant change is made to an endpoint, the version number used in the path of the resource being requested will be increased.

However, some changes or additions are backwards-compatible and your applications should be flexible enough to handle them. These include:

• Adding new attributes to the response of an existing endpoint
• Changing the order of attributes of responses (JSON by definition is an object of unordered key/value pairs)

¶ Order & Store API Integrations

All integrations that handle order or store workflows must meet the following requirements to ensure correct order processing, fulfillment, and store operations.

Retail partners must meet all general requirements and recommendations below, in addition to the retailer-specific requirements and recommendations called out in the sections labeled “for retailers.”

¶ Required

• Support integration management endpoints, including Activate Integration, Retrieve Integration Config, Update Integration, and Remove Integration.
• Support for order notification and order failure webhooks.
• Adherence to the Eats order integration flow, including making explicit POST Accept, Deny, and Cancel requests with supported reason types.
• Support for store management endpoints, including Retrieve Store Status, Set Store Status, and Update Store Prep Time.
• Rejecting orders if allergens/special instructions are provided and they cannot be relayed to the POS.

¶ Required for retailers

• Adherence to the Retail Order Fulfillment API Guide for replacements and approval tracking, including marking items as found, proposing substitutions, respecting customer replacement preferences, receiving real-time customer responses, and finalizing fulfillment by marking the order as ready.
• Support for the Replacement Recommendation endpoint for suggesting replacements to pickers.
• Support for the Update Delivery Partner Count endpoint for large orders requiring more than one courier.

¶ Recommended

• Support for Disposable Items.
• Support for Allergens.
• Support for item-level special instructions.
• Support for cart-level (order-level) special instructions.
• Support for all available endpoints in the Store and Order API suites.

¶ Recommended for retailers

• Support for handling price-by-weight products across all applicable endpoints, including order details ingestion and found item actions in the Resolve Fulfillment APIs, for items sold by unit or by weight.

¶ Menu API Integrations

All integrations handling Store or Menu management should meet the following standards.

¶ Required

Full support of the Menu API^† where the partner has the ability to make programmatic updates to Eats menus including but not limited to the following fields:

• Accurate Item-Level/Order-Level Special Instruction Support Flags
• Tax Categories for Items (where applicable)
• Store-level Tax Area ID (zip +4) (where applicable)

^†Support for all V2 Menu API Suite endpoints is required.

¶ Recommended

• Restaurant Status
• Menu Image URLs
• Out of Stock (OOS) Item Adjustments

¶ Performance Standards

Integrations that support live marketplace stores must meet certain performance criteria in order to remain active on Eats. These criteria include a baseline injection success rate that will be monitored daily and shared with mutual and prospective customers. Once integration stability is confirmed, this reporting may be configured for a weekly cadence.

Integrations that fail to meet a 99% injection success rate can be subject to revoked API access and/or removal or disabling of restaurant stores from the Eats marketplace. The degree of API access limitation will be determined by:

1. Magnitude of the difference between the expected and actual performance criteria.
2. Amount of time the expected performance criteria rate wasn’t met.

Any review or evaluation of a partner’s performance metrics will take into consideration the products and workflows used in the integration.