fetchUberEatsPromotion

Get one UberEats promotion, by id (ONE-3382).

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 a fabricated promotion.

Failures beyond the document-wide codes: 404 when promotionId does not exist or belongs to another organization — indistinguishable by design, as everywhere else on this API.

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.