Eats API Change Log
Keep track of changes and improvements to the Uber Eats APIs.
Eats APIs are versioned at the endpoint-level. With the exception of privacy or security fixes, introduction of a backwards-incompatible change will result in the version number of the API being incremented. Backward-incompatible changes will be communicated 90 days in advance so as to not interrupt integrations. A majority of Uber Eats API changes are backward-compatible and can be adopted as soon as released.
¶ 2023-09-18 New Order & Store API Suites
Order API Suite - Store API Suite
At Uber, our relentless pursuit to provide superior services and tools for our partners is at the heart of our operations. With this in mind, we are thrilled to announce the forthcoming release of our new Store and Order Management API suites.
This significant advancement is a strategic initiative to synchronize our support methods and better equip your external platforms to handle the needs of our shared platform users. By aligning the capabilities of our merchant live order fulfillment application (Uber Eats Orders Android / iOS) with our API suites, we aim to provide you with an enhanced, efficient, and streamlined toolset that mirrors our in-house application functionalities. We believe this will empower you with more robust tools to innovate and grow with our platform.
New Features include
- Schedule Order Webhook for additional notification at time of order placement.
- Adjust Order Fulfillment Endpoint and Webhook to enable adjustment of orders with your customers.
POST Resolve Fulfillment Issues
&order.fulfillment_issues.resolved
. - Store Status Webhook notifications from Uber when a store’s status has been adjusted.
¶ 2022-03-25 Order API: Addition of Tax Reporting fields in Get Order Details
Added New fields in order payload taxReporting with tax detail breakdown
- Tax Location ID for the Eater and Store
- Tax Labels for each item in the Cart
- Tax Reporting structure in Accounting
¶ 2022-01-08 Integration API: Enhancements and rebranding of Integration Config API
In an effort to consolidate and standardize external integration metadata and configurations, Uber is enabling new fields to fetch application specific metadata via the GET
/pos_data
endpoint and update it using the PATCH
& POST
/pos_data
endpoints. For ease-of-use, the individual and paging GET
/stores
endpoint(s) will now also include pos_data
as a store sub-field.
Activate and Update Integration Details
- Added
is_order_manager
– set this flag to true if you want to nominate your app for managing the core order workflow. The order manager app is responsible for accepting; rejecting; or canceling orders on behalf of the merchant. Most apps will be required to perform follow-up actions to complete the process: you must listen and respond to thestore.provisioned
webhook. As there can only be one order manager, if your app is eventually promoted, any existing order manager app will be demoted. Note: you should not request this flag if your app is passively observing store and order activity. - Added
integrator_store_id
– developer’s unique store-specific ID for reference. - Added
integrator_brand_id
– developer’s unique brand-specific ID for reference. - Changed name of
partner_store_id
to merchant_store_id in Activate Integration endpoint - Changed name of
pos_integration_enabled
to integration_enabled in Get Integration Details and Update Integration Details endpoints - Deprecated
pos_integration_enabled
field in Activate Integration
Get Order Details
- Added
order_manager_client_id
– order manager of the order. This client ID is the only client ID that can accept the orders. If you are not the Order Manager, your client ID is not responsible for accepting, denying, or canceling the order. - Added
integrator_store_id
– developer’s unique store-specific ID for reference. - Added
integrator_brand_id
– developer’s unique brand-specific ID for reference. - Added
merchant_store_id
– merchant unique store-specific ID for reference.