fetchUberEatsPromotions

List the UberEats promotions your organization's storefronts are running, with cursor pagination.

If Uber Eats refuses the call (for example, because the promotions scope is withdrawn), it fails with a typed dependency error naming the scope, never an empty page, which would falsely claim your storefronts are running no promotions.

ONE-3386 — PER STORE, ONLY UBEREATS' FIRST PAGE. UberEats' own list takes no paging parameter, so for each store this lists the promotions on the first page UberEats serves, and a promotion past that page is not listed. states and promotionIds filter that set, and page pages through it across your stores.

ORDER. Store by store, in the order of storeIds (or of your organization's Uber Eats stores when you omit it); within one store, newest createdAt first, then promotionId. A promotion with no createdAt comes last in its store.

ONE-3290 — A SHARED STOREFRONT IS LISTED ONCE. When several of your stores are connected to the same Uber Eats storefront, its promotions are listed once, under one of those stores' ids.

WITH NO storeIds, stores that are not connected to an Uber Eats storefront are skipped, and so is a store Uber Eats cannot list; naming such a store in storeIds is a 404 (ONE-2990).

Failures beyond the document-wide codes: 404 when any storeId is not a store of your organization — an unknown id and another tenant's id are indistinguishable by design.

Promotions on the connected delivery platforms. Organization-scoped like every other section: the organization is the one the API key authenticates and no request field can name another.

FOUR OPERATIONS (ONE-3382 reversed the earlier THREE-operation decision, 2026-09-24 — see the file header). fetchUberEatsPromotions (list), fetchUberEatsPromotion (get one, by id), createUberEatsPromotion and revokeUberEatsPromotion are the whole UberEats lifecycle: no update and no pause exist platform-side, and a promotion is immutable once created. fetchUberEatsPromotion is its own operation — matching the published docs site and the fetchStore / fetchOrder convention this API already follows elsewhere — rather than fetchUberEatsPromotions with one entry in promotionIds, even though the latter can answer the same question.

NAMED FOR THE PLATFORM IN THE METHOD, NOT THE PATH. The section is Promotions because DoorDash and Grubhub belong beside these, and the platforms differ materially: DoorDash exposes no promotion WRITE api to integrations at all, and Grubhub no promotions surface whatsoever — for both, promotion attribution arrives on the ORDER payload instead (see the Orders section, live today). A single fetchPromotions returning a union of three platform models would be worse for a generated client than one named operation per platform. So the path is /management/promotions and the operations name UberEats.

createUberEatsPromotion and revokeUberEatsPromotion are WRITES and are classified as such in ManagementApiKeyHook — a read-only api key is refused with 403.