revokeUberEatsPromotion
Revoke a promotion. TERMINAL — there is no un-revoke, on this API or on the platform.
If Uber Eats refuses the call (for example, because the promotions scope is withdrawn), it fails with a typed dependency error naming the scope, and nothing is revoked.
The reply carries the promotion in its new state, so confirming the revoke needs no follow-up read. Revoking stops the promotion going forward; it does not reverse redemptions already made, and it refunds nothing.
Failures beyond the document-wide codes: 403 when the api key is read-only; 404 when promotionId does not exist or belongs to another organization — indistinguishable by design, as everywhere else on this API.
Request
- promotionIdstring
REQUIRED. The
promotionIdfromcreateUberEatsPromotionorfetchUberEatsPromotions.
{
"promotionId": "00000000-0000-0000-0000-000000000000"
}Responses
- promotionUberEatsPromotion
The promotion, now
revoked. Returned so you need no follow-up read to confirm.
About Promotions
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.