¶ Testing using the Robo Courier

The Robo Courier is a new test automation tool for Uber Direct, now available in Open Beta to developers using the DaaS APIs. (Coming soon to Taiwan, Spain, and Mexico). Previously, the only way to test a delivery was to manually use the Driver app to spoof the pickup, delivery, and delivery verification actions. Instead, with the Robo Courier enabled, these events will occur automatically at set intervals after the order is placed.

¶ Enabling Robo Courier

To have the Robo Courier automatically deliver your test order, include the following object in the JSON data you POST to CreateDelivery:

"test_specifications": {
    "robo_courier_specification": {
        "mode": "auto"
    }
}

If you are using curl, you can use the parameter:

--data-urlencode 'test_specifications={"robo_courier_specification": {"mode" : "auto"}}'

¶ Robo Courier behavior

When set to auto mode, the Robo Courier will deploy on the following schedule:

Event	When it occurs	Example order placed at 1:00pm
0. Courier assignment	Default: Immediately (When no pickup window nor dropoff window are set)*	1:00:00pm
1. Courier is enroute	Immediately after Courier is assigned	1:00:30pm
2. Pickup is imminent	30 sec later	1:01:00pm
3. Courier picks up	30 sec later	1:01:30pm
4. Dropoff is imminent	30 sec later	1:02:00pm
5. Courier drops off	30 sec later	1:02:30pm

* If only pickup ready time (pickup_ready_dt) is set, the courier will be assigned at that given time. If only dropoff ready time (dropoff_ready_dt) is set, the courier will be assigned 10 minutes before the dropoff window opens.

¶ Verification Requirements

Any Verification Requirements specified by the delivery (e.g. signature capture, photo capture, ID verification, PIN code verification, barcode scanning, sobriety check) will be completed successfully by the Robo Courier, both at pickup and dropoff. Webhooks will still be sent normally as the Pickup and Delivery occur, and will contain information reflecting the completed Verification Requirements.

¶ Custom mode

If 30 seconds is still too long (or too short) for you to wait, or if you want to set up various time-based testing scenarios, you can do so by setting the Robo Courier mode to custom:

"test_specifications": {
    "robo_courier_specification": {
        "mode": "custom",
        "enroute_for_pickup_at": "2022-05-16T05:05:01Z",
        "pickup_imminent_at": "2022-05-16T05:06:03Z",
        "pickup_at": "2022-05-16T05:07:01Z",
        "dropoff_imminent_at": "2022-05-16T05:08:01Z",
        "dropoff_at": "2022-05-16T05:08:01Z"
    }
}

For each event, you can specify the exact timestamp for when it will occur. All fields shown are required in custom mode.

¶ Timestamp restrictions

• enroute_for_pickup_at
  • If a pickup window is specified, must occur within the pickup window
  • Else, must occur within 30 minutes of the order being placed
• dropoff_at
  • Must be within 8 hours of pickup time

¶ Space out Robo Courier deliveries

The Robo Courier can only be deployed for one ongoing delivery at a time. We recommend that you wait at least 90 seconds before redeploying the Robo Courier for a subsequent delivery from the same pickup address. If you place multiple orders consecutively, they might get automatically batched together, and you will receive unexpected & inconsistent webhooks.

Alternatively, to avoid this delay, use different pickup locations that are far apart from each other. In that situation, you can call the Robo Courier about 10 seconds after the previous deployment completes.

This feature should not be used for stress testing at this time.

¶ Cancellation reasons

The Robo Courier can also simulate delivery cancellation scenarios:

"test_specifications": {
    "robo_courier_specification": {
        "mode": "auto",
        "cancel_reason": "cannot_access_customer_location"
    }
}

Possible values for cancel_reason:

• cannot_access_customer_location
• cannot_find_customer_address
• customer_rejected_order
• customer_unavailable

When the Robo Courier navigates close to the dropoff location, you will receive a delivery status webhook indicating courier_imminent. Then, the courier will cancel the order using the reason code specified above. You will receive a delivery status webhook indicating cancellation.

The cancellation_reason field in the webhook will be populated with the reason code specified. No dropoff verification actions (e.g. ID verification, signature) will be performed.

¶ Undeliverable actions

When you initially call CreateDelivery, you should specify the undeliverable_action the courier should take if the order is canceled:

undeliverable_action	Behavior
leave_at_door	Courier leaves delivery at door.
return	Courier returns delivery to store. A return trip is created automatically and assigned to that courier. The courier will return the item(s) to the pickup address. You will receive additional webhook notifications for tracking the return trip.

If you do not specify an undeliverable_action in your CreateDelivery request, the default action is to return.

This value will be propagated back to you when you receive the cancellation webhook: It contains an undeliverable_action field populated with the value you specified (or blank if you omitted).

¶ Beta feature feedback

The Robo Courier feature is in Open Beta, and we are seeking your feedback via this form. Please also use this form to report any unexpected behavior. Thank you!

¶ FAQ

• Does the Robo Courier follow a real route from the Pickup location to the Dropoff location?

  • No, the Robo Courier does not navigate street-by-street from Pickup to Dropoff. Instead, it “teleports”:
    • When the order is received, the Robo Courier spawns at a randomly selected location near the pickup address, so it can take the delivery.
    • When the pickup_imminent time hits, the courier is directly placed at the pickup address (it teleports).
    • When the dropoff_imminent time hits, the courier is directly placed at the dropoff address (it teleports).

• Do we only get delivery_status events for test deliveries using Robo Courier, or do we get courier_update webhook events as well?

  • You will receive both types of events as long as you are subscribed to them. However, for courer_update events, the courier lat/long locations will be fixed to one of the three locations mentioned above (Spawn location, pickup location, or dropoff location).

• Are there any other known limitations to the Robo Courier?

  • Not currently supported in Taiwan, Spain, South Africa, Germany and Mexico. Support for these regions will be added later.
  • No support for Parking Bay Check-in (the courier_check_in delivery status event)
  • No batching (having a single Robo Courier pickup/dropoff multiple orders at a time)

• Can I still do manual testing (via the Driver app)?

  • Yes, Robo Courier will only be triggered when the test_specifications attribute is sent in a CreateDelivery request. If you want to manually test a delivery, omit this attribute from your request.