Need More Time (NMT)

Need More Time lets partners signal to Deliveroo that a picker needs additional time to complete an order. The signal adjusts dispatch timing so that rider arrival better aligns with order readiness, reducing wait times for both pickers and riders. If a rider has been assigned to an order, we will use the signal to better refine our rider dispatcher model, however, it will not change the times on the current order.

How It Works

When a picker realises they need more time on an order, your system makes a single NMT call with the number of additional minutes required (1–20) we strongly suggest increments of 2, preventing pickers from automatically resorting to 20 minutes as a default. Deliveroo records the request against the order, extends the prep stage on the dispatch side, and locks the order against any further NMT calls.
NMT is one-shot per order: once granted, the same order cannot be extended again. If a rider has been assigned to an order, we will use the signal to better refine our rider dispatcher model, however, it will not change the times on the current order.

Eligibility

NMT is available when all of the following conditions are met:

• JIT/ORCA order -- The order must use just-in-time rider assignment (rider_assignment_flow: JUST_IN_TIME). Pre-assigned orders are not eligible.
• Order is pickable — The order must not have reached a terminal status (accepted, rejected, cancelled).
• Not already requested — NMT can only be granted once per order. A second call returns 422 NMT_ALREADY_REQUESTED.
• Rider has not been assigned.

Endpoint

PUT /picking/v1/orders/{order_id}/request-more-time

Request

{
  "additional_minutes": 4
}

Response (200 OK)

{
  "order_id": "drn:order:abc123",
  "additional_minutes_granted": 4,
  "dispatch_timing_affected": false
}

Response fields

Guardrails

NMT enforces the following constraints per order:

NMT is a one-shot request: a successful call locks the order against further NMT requests, and any subsequent attempt for the same order returns 422 NMT_ALREADY_REQUESTED. Choose the requested minutes carefully — there is no top-up.

Error Codes

Understanding dispatch_timing_affected

The dispatch_timing_affected field is currently always false. It is retained in the response only for backward compatibility with clients that consumed the field before the NMT refactor, and you should not branch on its value. Eligibility (including any restrictions tied to rider state) is enforced server-side: if NMT is not appropriate for the order, the request is rejected with 422 ORDER_NOT_PICKABLE rather than accepted with dispatch_timing_affected: false.

Webhook & Order-Payload Update

After a successful NMT call, the order's webhook payload and any subsequent GET order responses include a new field:

{
  "order_id": "drn:order:abc123",
  "...": "...",
  "nmt_minutes_added": 4
}

Treat the webhook as the authoritative confirmation that NMT has been recorded for the order. Do not recompute or extend prepare_for locally -- Deliveroo's dispatch models may adjust the effective deadline beyond the raw minutes granted.

What NMT Does Not Do

• NMT does not extend auto-rejection time. If your site uses auto-rejection for orders that are not accepted within a time window, NMT does not affect that timer.
• NMT does not replace amendments. Use amendments to report item changes (removals, substitutions, weight adjustments). NMT only affects dispatch timing.
• NMT does not replace acceptance. You must still call the accept endpoint when the order is ready. NMT is not a way to hold an order indefinitely.

Recommended Integration Flow

1. Receive order -- check rider_assignment_flow. If the value is JUST_IN_TIME, the order is eligible for NMT.
2. Start picking -- call the start-picking endpoint as normal.
3. Picker needs more time -- call the NMT endpoint once with the total additional minutes needed (1-10).
4. Handle the response -- on 200, the request is granted. On 422 NMT_ALREADY_REQUESTED, surface the state to the picker rather than retrying.
5. Continue picking -- NMT does not interrupt the picking flow. Continue scanning items and submitting prep-state updates.
6. Submit amendments -- if items are unavailable, substituted, or need weight adjustments, submit amendments as normal.
7. Accept order -- once all items are picked and amendments submitted, call the accept endpoint.

NMT is single-shot per order; the picker should estimate the total additional time needed and submit it in a single call. The granted minutes will be reflected in the order's nmt_minutes_added field on the next webhook delivery.

Sequence Diagram

Code Examples

cURL

curl -X PUT \
  "https://api.deliveroo.com/picking/v1/orders/drn:order:abc123/request-more-time" \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"additional_minutes": 4}'

Common Questions

Does NMT work on all orders?

No. NMT is only available on JIT/ORCA orders (where rider_assignment_flow is JUST_IN_TIME). Pre-assigned orders are not eligible because dispatch has already been committed.

Can I call NMT before starting to pick?

Yes. NMT does not require the start-picking endpoint to have been called first. However, in practice, the picker usually discovers they need more time after picking has begun.

Can I request more time after I've already requested NMT once?

No. NMT is a single one-shot request per order. A second call returns 422 NMT_ALREADY_REQUESTED. The intent is that the picker estimates total additional time needed and submits it in a single request (up to 10 minutes).

Does NMT affect the auto-rejection timer?

No. Auto-rejection is a separate mechanism. If your site auto-rejects orders that are not accepted within a configured window, NMT does not extend that window. You must still accept the order before the auto-rejection deadline.

Can I use NMT and amendments together?

Yes. NMT and amendments serve different purposes. NMT adjusts dispatch timing; amendments adjust order contents. They are independent and can be used in any order during a picking session.

Is the NMT endpoint idempotent?

No. The first successful call grants the requested minutes; any further call for the same order returns 422 NMT_ALREADY_REQUESTED. Retrying after a 5xx response is safe -- the worst case is a duplicate that is rejected with 422.

Is the endpoint rate limited?

Yes - If you exceed this, the API returns 429 RATE_LIMITED. Implement exponential backoff before retrying.