Skip to main content

Order Acceptance

Overview​

When Stream sends an order via the Handle Order (Stream -> POS) endpoint, your POS must respond to indicate whether the order can be fulfilled.

Standard Order Acceptance​

Upon a successful 200 response with order.created event type, Stream considers the order accepted and inserted into the POS successfully. At this point, the DSP is notified that the order is accepted.

Required Response Fields​

The only required field in a successful 2xx response is:

  • order.provider_id - Your POS order ID, used for all future communication about this order

Response Example​

{
  "order": {
    "provider_id": "pos-order-12345",
    "prep_time_minutes": 15
  }
}

Dynamic Prep Time​

Stream manages preparation time at two levels. Understanding both is important for providing accurate timing to customers at each stage of the order flow.

Location-level prep time (location.prep_time_minutes)​

Set on your Get Locations response, this is the default prep time for the location. DSPs use this value to display estimated wait times to customers before they place an order — for example, on a storefront listing. It is a static value that represents your typical preparation time under normal conditions.

{
  "provider_id": "location_123",
  "name": "Downtown Branch",
  "prep_time_minutes": 20
}

To update this value, you would need to trigger a location resync.

Order-level prep time (order.prep_time_minutes)​

Returned in your order acceptance response, this is an optional per-order override of the location-level prep time. DSPs use this value to display a confirmed preparation time to the customer after their order is placed and accepted.

If order.prep_time_minutes is not included in your acceptance response, Stream will fall back to the location's prep_time_minutes automatically — no resync required.

{
  "order": {
    "provider_id": "pos-order-12345",
    "prep_time_minutes": 12
  }
}

Use this field to dynamically adjust prep time per order based on real-time factors such as:

  • Current kitchen load
  • Order complexity
  • Time of day
  • Staff availability

Future Orders​

Some DSP platforms support scheduling orders in advance. When this occurs:

  • is_future_order will be set to true
  • requested_for will contain the estimated fulfillment time

Other DSP platforms, for example, Uber & DoorDash, hold the order on their end and notify Stream closer to the fulfillment time. You will not receive advance indication that it was a future order.

Async Order Acceptance​

If your POS integration needs additional time to validate or manually review orders before acceptance, see Async Order Acceptance for the deferred acceptance workflow.

When to Use Async Acceptance​

Use async acceptance when your POS needs to:

  • Queue orders for manual review by staff
  • Run extended validation processes
  • Check external systems before confirming

Quick Example​

Respond with async_acceptance: true to defer the decision:

{
  "order": {
    "provider_id": "pos-order-123",
    "prep_time_minutes": 15,
    "async_acceptance": true
  }
}

Then send a webhook event within 60 seconds to confirm or reject.

See the full async order acceptance documentation for complete details.

Order Rejection​

If your POS cannot fulfill the order, return a 400 status code with validation details. See Order Rejection & Validation for details on validation types and error formats.