¶ Product estimates Flow:

¶ User Input

Your platform’s user interface (UI) should allow user to input key trip details before calling the Estimates Endpoint. Alternatively, this information can be auto-populated from another system.

Required Trip Information:

• Pickup and Drop off Location (Ideally refined through the Pickup Refinement Flow).
• Ride Type: On-Demand, Scheduled Pickup, or Flexible Pickup. Although the rider’s information isn’t mandatory to call the Estimates endpoint, it’s best to collect everything upfront to streamline the process of creating the trip.

¶ Ride Types Supported by Guest Trips API:

• On-Demand: The ride is requested immediately.
• Scheduled Pickup: Set a specific date and time for the ride in the future (use scheduling.pickup_time).
• Flexible Pickup: The guest decides when to request the ride on a specified date. They receive instructions via SMS (use deferred_ride_options.pickup_day). It’s generally recommended to build support for all three ride types unless there’s a specific reason not to.

¶ Checking Product Availability

Uber’s products are widely available, but if the Estimates Endpoint returns an empty product or fare estimate list, it’s likely due to an invalid pickup location (e.g., coordinates like 0,0). Ensure that the locations are valid before calling the endpoint.

¶ ETA and Fare Information

When receiving estimates, there are three potential outcomes:

• ETA and Fares are Available: The API returns products, their fares, and an ETA. This is typical for on-demand rides.
• ETAs are Unavailable, but Fares are Returned: Common for scheduled or flexible rides where the ETA is unknown at the time of the request.
• Fares are Unavailable: This indicates a server error. It is strongly recommended not to proceed without fare data.

¶ Display Product Options to the End user

Present the information from the Estimates Endpoint in your front-end. Recommended fields to display include:

• Product Name (using the display_name field).
• Product Image: Overlaid with a background image.
• ETA (from pickup_estimate).
• Fare Estimate.

¶ Grouping Products:

When building the ability to categorize products in your front-end, use parent_product_type_id to organize products across different markets.

• High level product grouping:

  Products like UberX and Uber Black are managed at the city level and map up to parent_product_type_id across markets.

• Category based product grouping:

  If you need to group products within the same category (e.g., UberX across multiple cities), you should use string matching to handle potential variations in product names [display_name].

  • Naming Variations: While standard naming conventions are used, there may be occasional differences due to manual entry errors or local customizations.

  • Error Handling: If product names don’t match what you expect, contact Uber to investigate and resolve any discrepancies.

  By using this method, you can easily group and manage products consistently across different markets.

• Handling no_cars_available = TRUE:

  If the response includes no_cars_available = TRUE, the platform has detected no nearby drivers for the ride request. While a trip can still be requested, it’s recommended to notify the user that a driver may not be found, and the request may fail.