Uber Developers

API Flows

Privileged and Confidential This endpoint design has been confidentially shared with you. It is still under development and is subject to change without notice. Please do not share this document or API endpoint details with anyone who is not authorized to have access. For more information read about scopes.

This guide describes the recommended API call sequences for each major user-facing flow in a third-party rides integration. Each flow maps to a specific user journey and lists the endpoints to call, in order, along with the key data passed between them. Please note this is just the recommended flow, the apis being called can change based on partner.

¶ 1. Product Selector / Home Screen

This flow powers the experience when a rider opens the app and selects a pickup and dropoff location. It shows available products, vehicle availability on the map, price estimates, and applicable promotions.

ResolveWaypoint          ← Resolve pickup/dropoff to zone or access point (high-density venues only)
       ↓
GetAvailableProducts(optional)     ← Fetch all products available at origin/destination
       ↓ (can be called in parallel)
GetNearbyVehicles        ← Show nearby vehicles
GetEstimatesForIntent    ← Fetch price, ETA  per product

Step	Endpoint	Key Inputs	Key Outputs
1	ResolveWaypoint	pickup/dropoff lat-long	access_points, zone_info
2	GetAvailableProducts	origin, destination	product list
3a	GetNearbyVehicles	rider lat-long, product ids	vehicle positions for map
3b	GetEstimatesForIntent	origin, destination, product ids, user_id	fare_id, price, ETA per product

Note ResolveWaypoint is only needed when the pickup or dropoff is at a high-density venue (airport, hospital, arena). For standard addresses, start with GetAvailableProducts directly.

Note GetNearbyVehicles and GetEstimatesForIntent are independent of each other and can be called in parallel.

¶ 2. Trip Request (Create Order)

This flow covers the moment a rider confirms their ride. The fare_id from GetEstimatesForIntent is passed to CreateOrder to lock in the price.

GetEstimatesForIntent    ← (reuse from Product Selector — fare_id is the key output)
       ↓
CreateOrder              ← Create the order using fare_id + product + payment_profile
       ↓
GetOrder (polling)       ← Poll for order state updates (driver search → assigned → en-route)

Step	Endpoint	Key Inputs	Key Outputs
1	GetEstimatesForIntent	origin, destination, product_id, user_id	fare_id, estimated fare
2	CreateOrder	fare_id, product_id, payment_profile_id, participant_spec	order_id, initial order status
3	GetOrder	order_id	order status, driver details, job_id, fare version

Note Pass the fare_id from GetEstimatesForIntent directly into CreateOrder to lock in the estimated price.

¶ 3. Active Trip (In-Trip)

Once an order is created and a driver is assigned, this flow manages in-progress trip interactions.

¶ 3a. Track Order (Polling)

GetOrder (polling)       ← Continuously poll to track driver location and order state transitions

Poll GetOrder on a reasonable interval to reflect latest order status in the UI.

¶ 3b. Modify Destination (Waypoint Change)

For destination changes during an active trip, always fetch a modification estimate first before applying the change. This shows the rider the updated fare before confirming.

GetEstimateForOrderModification  ← Fetch updated fare for the proposed destination change
       ↓ (rider confirms)
UpdateOrder                      ← Apply the waypoint update (update_target: UPDATE_TARGET_STANDARD_RIDE_DESTINATION_WAYPOINTS or UPDATE_TARGET_STANDARD_RIDE_ORIGIN_WAYPOINT)
       ↓
GetOrder                         ← Confirm updated order state and new fare

Step	Endpoint	Key Inputs	Key Outputs
1	GetEstimateForOrderModification	order_id, update_request_one_of (new destination)	estimated fare for modified route
2	UpdateOrder	order_id, update_request_one_of (DESTINATION_WAYPOINTS)	updated order
3	GetOrder	order_id	confirmed updated order

¶ 3c. Switch Payment Profile

To switch payment during an active trip, fetch the available payment options scoped to the order first, then apply the change.

GetPaymentSummary        ← Fetch available payment profiles for this order context, this api is available only for 1P uber users. Its skipped for 3p users.
       ↓ (rider selects a new profile)
UpdateOrder              ← Apply the payment profile change (update_target: PAYMENT_PROFILE)
       ↓
GetOrder                 ← Confirm the updated payment profile on the order

Step	Endpoint	Key Inputs	Key Outputs
1	GetPaymentSummary	user_id, order_payment_selection_criteria (with order_id)	available payment_profiles
2	UpdateOrder	order_id, update_request_one_of (PAYMENT_PROFILE, selected payment_profile_id)	updated order
3	GetOrder	order_id	confirmed updated payment on order

Note GetPaymentSummary accepts order_payment_selection_criteria to scope the returned profiles to what is valid for the specific order context (e.g. excluding profiles incompatible with the current market or product). Always use this scoped call — not a bare user-level fetch — when switching payment mid-trip.

¶ 4. Cancellation Flow

This flow handles a rider cancelling their ride. Present cancellation reason options, show the cancellation fee for the selected reason, then cancel.

GetSurvey                          ← Fetch cancellation reason options (CANCELLATION survey type)
       ↓ (rider selects a reason)
GetEstimateForOrderCancellation    ← Show cancellation fee and next set of actions available based on marketplace conditions
       ↓ (rider confirms)
CancelOrder                        ← Cancel the order with the selected reason

Step	Endpoint	Key Inputs	Key Outputs
1	GetSurvey	order_id, survey_type: CANCELLATION	cancellation reason options
2	GetEstimateForOrderCancellation	order_id, cancellation_reason	cancellation fee, available_actions
3	CancelOrder	order_id, cancellation_reason	cancelled order confirmation

Note If the rider exits the cancellation screen without selecting a reason, pass no cancellation_reason to GetEstimateForOrderCancellation — it defaults to a skipped reason and still returns the recommended actions and fee.

Note GetEstimateForOrderCancellation can return options like call driver, find new driver(unassignJob) as well.

¶ 5. Post-Trip Flow

After a trip completes, this flow covers the receipt, driver rating, and tipping.

¶ 5a. Receipt

GetOrder                 ← Fetch completed order — contains finalized fare, promo deduction, job_id, fare version

Step	Endpoint	Key Inputs	Key Outputs
1	GetOrder	order_id	finalized fare, promo deduction, job_id, fare_id, fare version

¶ 5b. Driver Rating

GetSurvey                ← Fetch driver rating options (TRANSPORT_PROVIDER_RATING survey type)
       ↓ (rider submits rating)
SubmitSurvey             ← Submit the driver rating response

Step	Endpoint	Key Inputs	Key Outputs
1	GetSurvey	order_id, survey_type: TRANSPORT_PROVIDER_RATING	rating questions and options
2	SubmitSurvey	order_id, survey responses	(empty response)

Note Only TRANSPORT_PROVIDER_RATING submissions are persisted. SubmitSurvey always returns an empty body regardless of survey type.

¶ 5c. Submit Tip

Tipping requires three values from GetOrder: order_id, job_id, and version (the fare version from the finalized fare object).

GetOrder                 ← Retrieve job_id, tipping rules and fare version from finalized fare
       ↓
SubmitTip                ← Submit tip using order_id + job_id + fare version + tip amount

Step	Endpoint	Key Inputs	Key Outputs
1	GetOrder	order_id	job_id, fare version (from finalized fare)
2	SubmitTip	order_id, job_id, version, tip_amount	(empty response)

Note SubmitTip requires both order_id and job_id. The job_id and the fare version are returned by GetOrder in the finalized fare section — cache both when fetching the receipt. Submitting a tip with a stale fare version returns ERROR_CODE_FARE_VERSION_INCORRECT.

Note Only post-trip tipping is supported (order must be finalized). On-trip tipping is not yet available.

¶ Complete Endpoint Reference

Endpoint	Resource	Flow(s)
ResolveWaypoint	POST /v1/rides/resolve-waypoint	Product Selector
GetAvailableProducts	POST /v1/rides/products	Product Selector
GetNearbyVehicles	POST /v1/rides/get-nearby-vehicles	Product Selector
GetEstimatesForIntent	POST /v1/rides/estimates	Product Selector, Trip Request
GetEstimatesForIntentForTMS	POST /v1/tms/rides/estimates	Trip Request (TMS partners only)
GetPaymentSummary	POST /v1/payments/get-summary	Product Selector, Active Trip (payment switch)
GetUserPromotions	POST /v1/users/promotions	Product Selector, Post-Trip, Promotions
CreateOrder	POST /v1/rides/create-order	Trip Request
GetOrder	POST /v1/rides/get-order	Trip Request, Active Trip, Post-Trip
GetEstimateForOrderModification	POST /v1/rides/order-modification-estimate	Active Trip (waypoint change)
UpdateOrder	POST /v1/rides/update-order	Active Trip (waypoint change, payment switch, product change)
UnassignJob	POST /v1/rides/unassign-job	Active Trip (new driver request)
GetCashCollectibleLineItems	POST /v1/payments/cash-collectible-line-items	Active Trip (cash payment)
GetSurvey	POST /v1/rides/get-survey	Cancellation, Post-Trip (driver rating)
GetEstimateForOrderCancellation	POST /v1/rides/order-cancellation-estimate	Cancellation
CancelOrder	POST /v1/rides/cancel-order	Cancellation
GetFare	POST /v1/rides/get-fare	Post-Trip (receipt)
SubmitSurvey	POST /v1/rides/submit-survey	Post-Trip (driver rating)
SubmitTip	POST /v1/rides/submit-tip	Post-Trip
ApplyPromotionToUser	POST /v1/users/promotions/apply	Promotions
CreatePromotionCode	POST /v1/promotions/create-code	Promotions (ops-initiated)
SendCommunicationToUser	POST /v1/comms/send	Communications (Uber → 3P)
SendThirdPartyCommunicationToUser	POST /v1/comms/send	Communications (3P → Uber)
CommunicationCallbackEvents	POST /v1/comms/callbacks	Communications
PublishAnalyticsEvents	POST /v1/analytics/publish	All flows