Skip to main content
Nash sends the shift.dispatched webhook when a delivery window (shift) passes its cutoff and its confirmed orders are dispatched as a batch — one event that tells you which orders became jobs (deliveries) and which failed, grouped by organization, store location, pick shift name, and cutoff date. Event Type: shift.dispatched
Entity Type: shift
Event Name: dispatched
Shift dispatched sequence diagram

When is this webhook triggered?

The webhook is triggered when:
  1. Automatic Dispatch: The system automatically dispatches orders from delivery windows that have passed their cutoff time
  2. Bulk Processing: Orders are grouped by organization, store location, pick shift name, and cutoff date
  3. Validation: Each order in the group is validated before dispatch; failures are reported in the errors field while the remaining orders dispatch

Validation rules

Before orders are dispatched, the system validates each order against the following criteria:

Order-level validations

  1. Delivery Window Status
    • Delivery window status must be confirmed
    • Orders with other statuses (e.g., pending, canceled) are skipped
  2. Cutoff Time
    • Cutoff time must have passed
    • Orders with future cutoff times are not dispatched
  3. Order Status
    • Order must not already be in dispatched or archived status
    • Prevents duplicate dispatches

Group-level validations

  • All orders in a store/shift group must meet the criteria above
  • If any order fails validation, it’s reported in the errors field
  • Successful orders still get dispatched; the webhook includes both successes and failures

Webhook payload structure

The webhook payload follows this structure:

Payload fields

A job that is created but then fails provider dispatch appears in errors keyed by its job_ ID, not in created_job_ids — see Scenario 3.

Webhook scenarios

Scenario 1: complete success

All orders in the shift are successfully dispatched to jobs. Example Payload:
Interpretation:
  • 4 orders were successfully dispatched
  • No errors occurred
  • Each job ID corresponds to one order being delivered
  • All orders from the shift are now in the delivery system

Scenario 2: partial success with validation errors

Some orders succeed while others fail validation checks. Example Payload:
Interpretation:
  • 2 orders successfully dispatched (jobs created)
  • 2 orders failed validation and were not dispatched
  • Failed orders need to be corrected and re-dispatched manually
  • The validation error messages provide details on what needs to be fixed

Scenario 3: partial success with provider errors

Orders pass validation but fail when dispatching to the delivery provider. Example Payload:
Interpretation:
  • 2 orders successfully dispatched to the provider
  • 1 order failed at the provider dispatch stage (after job creation)
  • 1 order failed validation and was not dispatched
  • Provider errors may indicate capacity issues, service area restrictions, or provider API problems
  • Orders with provider errors may have jobs created but not accepted by the provider

Error types reference

Order validation errors

Order validation errors come from Nash’s order validation. See the full validation rules in Order validations. Common validation error patterns:

Required fields

Store location errors

Address and location errors

Phone number errors

Value and type errors

Delivery mode and datetime errors

Currency and requirements errors

External ID errors

Items errors

Provider dispatch errors

Delivery windows

The bookable slots whose cutoffs trigger this event.

Webhooks

Set up endpoints, verify signatures, and handle retries.