¶ Overview

Uber Eats provides merchants with multiple mechanisms for activating and configuring their live production stores against a given app integration.

1. During onboarding, Uber may pre-integrate a store with integrator mapping details.
2. Once live, by the merchant contacting Uber technical support teams.
3. Through an integration partner’s own website, by merchant’s authorizing you app with OAuth login flow, allowing you to call the GET /stores and POST /pos_data endpoints. See details below.

In each case, apps will be be notified of any initial and subsequent changes to their store integration status via the store.provisioned webhook. To provide a cohesive merchant experience, you should listen and respond to these webhooks. This is especially important if your app is responsible for core order workflow management (accepting; rejecting; or cancelling orders) as you may be requested to do follow-up actions (e.g. upload a menu).

If the integration details are wrong, or your integration is unable to operate the store, you should modify or deactive the integration via PATCH /pos_data. Should your app ever be deactivated from a store, you will receive a store.deprovisioned webhook.

Once an app is activated against a given store, its client_credentials access token(s) will be able to call most APIs; and it will start to receieve webhook notifications related to the store.

Using GET /pos_data; PATCH /pos_data; and POST /pos_data endpoints, integration partners can read and write their ID and configuration data against each store to facilitate mappings and debugging. For convenience, a subset of this integrator store data is also available when fetching or enumerating store details via the GET /stores endpoints.

¶ Triggering Activation From 3rd Party Workflow

• Authorization
  Developers can redirect users to Uber’s OAuth login flow, temporarily authorizing your app to access their stores.
• Retrieve Stores
  Upon authorization, developer can retrieve all stores associated to the authorizing merchant via GET /stores. This call returns Uber’s unique identifier and store location data. Developer must map Uber’s unique ID to correct stores using the location data. External store ID can be arbitrary and should not be used as a sole matchpoint.
• Activation
  Developers can activate their app against a store the POST /pos_data endpoint using the merchant user’s access token. This grants your app with perpetual access to the store.
• Deactivating
  Developers can temporarily de-activate their app by setting integration_enabled to false with the PATCH /pos_data; or more permanently revoke integration by calling the DELETE /pos_data endpoints.

¶ Merchant Authentication Workflow

¶ Third-Party Activation Workflow

¶ FAQs

My token is not authorized for endpoints?

The user access token (authorization_code grant type) is active for endpoints below:

• GET /stores
• POST /pos_data
• DELETE /pos_data

Once a store is provisioned to a developer account via POST /pos_data, the developer will have access to the store using developer generated access token (client_credentials grant type). Developers should only use the user generated token when retrieving, provisioning or de-provisioning a merchant location.

Merchant is ready to provision the location but not ready to go live in the marketplace?

The Set Restaurant Status endpoint will enable you to pause the location so it does not appear within the Uber Eats marketplace. When the location is ready to launch, set restaurant status to ONLINE.

¶ Next Steps

Review the Store Integration guide.