Skip to main content
The Fleet API is the inbound surface a fleet uses to report state on deliveries Nash has dispatched to it — courier location, status transitions, proof of delivery, courier identity, ETAs, and notes. Use it whether you’re a merchant operating your own couriers or a third-party fleet receiving Nash demand. The contract is the same in both cases: Nash dispatches a job (delivery) to your organization, you fulfill it, and you PATCH updates back as the delivery progresses.

​
When updates start

Each dispatch event Nash sends carries a deliveryId. That’s the identifier you use on every update for that delivery’s lifetime. Updates only land on deliveries owned by your organization — anything else returns not-found.

​
Keep your driver roster in step

Nash needs to know who your drivers are before it can dispatch to them. If that roster lives in a system of your own, PUT /v1/fleet/drivers/upsert keeps the two in step without anyone retyping changes into the Portal. The endpoint is keyed on your own externalIdentifier, so there’s no separate create and update to choose between — send the driver, and the first call creates while every later one updates. A field you leave out keeps the value it already had, and you take a driver off the road by upserting isShiftActive: false rather than deleting them. The same call links vehicles, store locations, and driver groups, and provisions a driver-app login when you send an email address. See Upsert Driver for the full field list.

​
Two endpoints for delivery state

Both accept partial bodies — only the fields you want to change need to be present.

​
Lifecycle

A typical happy path moves through:
Terminal failures use failed or canceled_by_provider, paired with a structured failure.code (e.g. customer_unavailable, address_not_found, no_capacity). Returns flow through return_in_progress → return_arrived → returned_to_store. Sending the same status twice is a no-op, so it’s safe to retry.

​
What you can include in a single call

A single update can carry any combination of:
  • status — lifecycle transition.
  • coordinates — { latitude, longitude }. Append-only; safe to send on every tick.
  • courier — name, phone, vehicle, profile image. Send on first assignment, or any subset on a mid-flight swap.
  • proofOfDelivery — image artifacts (photo / signature at pickup or dropoff) or barcode scans.
  • failure — structured { code, reason } for failed / canceled_by_provider.
  • pickupEta / dropoffEta — provider-supplied ETAs.
  • pickupNote / dropoffNote — free text the courier captured.
  • parkingLocation / returnParkingLocation — where the courier parked at the stop or when returning the package.
  • externalDeliveryId — your own identifier for this delivery, for cross-system reconciliation.

​
Validation

  • At least one mutating field is required per update — empty bodies return 422.
  • coordinates.latitude must be in [-90, 90], longitude in [-180, 180].
  • Wire format is camelCase; snake_case is also accepted.

​
Response shape

Both endpoints return the same delivery object you’d see nested under a job’s task in GET /v1/jobs/{id}. The bulk response wraps each item with a per-item success flag and either the updated delivery or a structured error.

​
Next steps

Report delivery state

Walk through reporting status, location, and proof of delivery.

Update a delivery

PATCH a single delivery as it progresses.

Bulk update deliveries

Flush updates for up to 100 deliveries at once.

Upsert a driver

Create or update a driver from your own system.