Order Rejection Control & Assurance (ORCA) through Just-in-Time (JIT) orders

Background

Standard orders (outside the JIT/ORCA flow) rely on preset picker timers that automatically reject or cancel orders if picking does not start or finish within a fixed window. These timers are manually configured and often fail to reflect real-time store conditions, seasonality, or operational variability. As a result, orders can be prematurely auto-rejected, leading to avoidable customer-experience degradation.

The JIT/ORCA flow addresses these limitations by dispatching riders in parallel with the store’s order release and picking process, using a prep-time model to better align rider arrival with expected picking completion. It also extends the auto-rejection timer, retaining it as a fallback only when no action is taken on the order. By surfacing the rider’s expected arrival time to pickers, JIT enables more transparent prioritisation and better order readiness, reducing picker–rider friction and improving end-to-end delivery times for customers.

📘

JIT vs ORCA

ORCA (Order Rejection Control and Assurance) is an initiative that changes when and how we dispatch riders and release orders to reduce auto‑rejections and improve delivery outcomes. It does this by adopting the Just‑in‑Time flow for orders, so riders are assigned based on predicted prep time rather than after picking is complete.

You may find it being used interchangeably. It helps to keep in mind that ORCA is the initiative and JIT is the mechanism ORCA uses to address the issue.

How the JIT order flow works

JIT temporarily holds an order after it’s placed, then calculates the best time to release it based on the given site’s picking speed, order complexity, and rider availability. Once it’s released, a rider is assigned straight away while picking is still ongoing, and the partners should be receiving live updates through the rider events webhook as the riders head to the site.

If a rider arrives and collects the order before the picker marks it as complete, Deliveroo will auto-complete the order on the partner's behalf (with the assumption that all the items on the order is prepared accounting for the active amendments).

📘

Key integration requirements

To support JIT, Picking API partners must implement

• Picker experience updates to reflect deadlines and live rider status
• JIT system signal handling for early rider dispatch
• Rider events webhook integration to track assignment and arrival

Picker experience updates

The picker experience for JIT is designed to ensure pickers remain aligned with rider arrival times rather than system-driven rejection timers.

📘

Functional prerequisites

Before enabling JIT on a site, the following foundational capabilities must be in place:

• Visibility latency: 99.9% of orders must appear on the in-store device within 30 seconds of webhook receipt
• Audible alerting: Device must emit audio notification for new orders, stopping automatically once picking begins
• Device availability: In-store devices must remain awake at all times to prevent disruption. This ensure pickers can begin fulfilment immediately which is critical for JIT's early rider dispatch model

Picker interface guidelines

The partner's picker interface must help pickers prioritise orders and manage the picking progress in sync with rider arrivals.

Timers and order prioritisation

The partner's picker interface should display pick completion expectation timers based on the earliest rider's estimated arrival time:

• Before a rider is assigned, use the predicted prep time (the prepare_for field)
• Once a rider is assigned, switch the countdown timer to the rider's estimated_arrival_time. This is the live rider ETA that updates in real-time as the rider travels to your site, providing accurate arrival predictions. If multiple riders are assigned to an order, always use the earliest estimated arrival time.

Timers must not be based on the auto-rejection deadline. Under JIT, the auto-rejection deadline is extended and serves only as a fallback mechanism. Orders should be sorted by earliest rider arrival: Overdue/Rider arrived first, then Rider nearby, then Rider en route.

Visual and audible notifications

The partner's picker interface should show real-time countdown (e.g., "Rider arriving in 3 mins") in both dashboard and order headers. Trigger distinct audio and visual alerts when riders arrive. Send recurring overdue notifications (every 3 minutes) if orders remain incomplete after rider arrival.

Edge case handling

If a rider collects an order before it's marked pick-completed, Deliveroo auto-completes it, assuming all items were successfully picked (accounting for those with amendment requests). The partner's picker interface should display a notification to the pickers that the order was collected and auto-completed, and is no longer editable. When a rider picks up the order, a rider status event with status, rider_in_transit, is sent to the Rider Events webhook.

Note: In case multiple riders are assigned to deliver an order, Deliveroo will auto-complete that order only when all the riders reach the rider_in_transit state.

Order release

JIT manages order release by synchronising it with rider's estimated arrival. The system uses prep-time and rider-confirmation models to calculate prepare_for (when the order should be ready). If a rider is going to take longer to arrive than the prep time, JIT delays the release, thus ensuring you receive the order at an optimal moment.

What changes: Previously, webhooks were sent immediately when orders were placed. For JIT orders, webhooks are sent only when orders are released.

Auto-rejection timer extension

JIT modifies auto-rejections in two ways:

• First, the auto-rejection timeout is extended to reduce the risk of premature rejections during operational challenges.
• Second, the timer starts from the JIT-determined release time (rather than order placement time), providing a fairer and more accurate deadline since JIT holds the order until optimal dispatch.

What changes: The auto-rejection timeout will be extended and reflected in the eta.start_picking_by and eta.end_picking_by fields.

Payload changes

• rider_assignment_flow — Indicates whether rider assignment is STANDARD or JUST_IN_TIME. Helps partner systems handle workflow appropriately.
• prepare_for — Time by which the order should be ready for rider pickup. Predicted by Deliveroo's prep-time model using order details, rider telemetry, and site's typical picking time.
• eta.start_picking_by and eta.end_picking_by — Auto-rejection timeout boundaries.

🚧

For JIT orders, don't use these timers for picker countdown. Use:

• prepare_for before rider assigned
• Earliest rider's ETA once riders assigned

Key differences

Sample Payload Excerpt

{
  "orders": [
    {
      ... other attributes
      "status": "placed",
      ... other attributes
      "prepare_for": "2025-11-19T10:32:22",
      "eta": [
        {
          "type": "start_picking_by",
          "timestamp": "2025-11-19T10:42:22.944664469Z"
        }
      ],
      "rider_assignment_flow": "JUST_IN_TIME"
    }
  ],
  ... other attributes
}

Rider events webhook integration

Rider events webhook integration is essential to ensure accurate and timely updates on rider status, which directly impacts the picking process and order flow. It enables the partner's system to track when a rider is assigned to an order, the number of riders assigned to a given order, when a rider is expected to arrive, when they actually arrive, and when they collect the order. These signals allow the picker app to display relevant deadlines, send overdue alerts, and automate state transitions—ensuring smooth handoffs even if pickers don't manually update the system. More guidance on this is available at the listening to rider events guide here.

Onboarding and testing

To onboard your testing sites, please contact your Technical Integration Manager and request that the production test sites be added to the necessary configurations, including an extension of their auto-rejection timeouts.