After retrieving full order details via GET /v2/eats/order/{order_id}, determine if the order can be fulfilled based on item availability and current kitchen capacity
To accept, POST to /v2/eats/order/{order_id}/accept_pos_order with a reason field set to a brief description; optionally include a minutes_to_ready field for prep time
To deny, POST to /v2/eats/order/{order_id}/deny_pos_order with a deny_reason_code (for example, ITEM_UNAVAILABLE or STORE_CLOSED) and a human-readable reason
If prep time changes after acceptance, send an updated minutes_to_ready value via the order update endpoint to adjust the estimated pickup time for the delivery partner
Monitor for order_cancel webhooks in case Uber or the customer cancels after your acceptance
Known gotchas
Using an invalid deny_reason_code returns a 400 error; consult the Uber Eats API reference for the current enumerated list before hardcoding values
Repeated denials with the code ITEM_UNAVAILABLE without corresponding menu updates can trigger a review of your store's integration health
minutes_to_ready is advisory; Uber Eats may dispatch a courier before the time elapses, so communicate delays proactively
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp