> ## Documentation Index > Fetch the complete documentation index at: https://docs.usenash.com/llms.txt > Use this file to discover all available pages before exploring further. # How Nash works > An end-to-end overview of the Nash delivery orchestration platform — the delivery lifecycle, the provider network, and the core building blocks you integrate with. Nash is a delivery orchestration platform that lets your business offer reliable delivery through a single integration. Nash connects you to a large network of fleet providers and drivers, and gives you the tools to create, dispatch, track, and recover deliveries — through the Nash Portal and programmatically through the Nash API. This page is the canonical overview of how the platform fits together. If you want to start building, jump to the [API overview](/api-reference/api-overview). Nash Introduction

## The delivery lifecycle Every delivery follows a clear, observable lifecycle. There are three logical phases: **Order Ingestion**, **Dispatch**, and **Tracking**.

Create

An order arrives with a pickup and a dropoff

Quote

Eligible providers and your fleet return priced quotes

Dispatch

Your strategy — or you — picks the provider

Track

Webhooks, the Portal, and live tracking, end to end

Recover

Failover re-quotes and reassigns if a provider falls through

The moment Nash acts The loop runs on every delivery

### Order Ingestion The starting point for Nash is information about a potential delivery. You submit pickup and dropoff details, package information, and timing requirements. This can come through the REST API, the GraphQL API, a CSV upload in the Portal, or an integrated demand source (such as Shopify or Toast). Typical fields include: * Pickup address * Dropoff address * Contact information * Package details * Delivery window You create this information as an **order** — directly in the Nash Portal, by CSV upload, or with the [Create Order](/api-reference/order/create-order) endpoint. Once the submitted information is validated, Nash returns a list of quotes from providers eligible to fulfill the delivery, each including price and estimated pickup and delivery times. Nash requests quotes based on factors such as geographic coverage, vehicle compatibility, package requirements, contract pricing, and real-time availability. ### Dispatch Dispatch is the set of actions that decide which provider fulfills the delivery. You can: * **Manually select** a provider from the returned quotes (in the Portal or via [Select Quote](/api-reference/order/select-quote)), or * **Automatically dispatch** using a [dispatch strategy](/reference/dispatch-strategies) that selects a provider according to your configured rules. Rather than attaching a strategy to every order yourself, you can use [Automations](/api-reference/dispatch-strategies/dispatch-automations) to map business rules to strategies at the account level — for example, route high-value orders to one strategy and everything else to another. This keeps decisioning logic in Nash instead of your application. The result of this phase is a delivery dispatched to a provider — at which point you have a **job** (delivery). ### Tracking Once dispatched, Nash provides continuous updates as the delivery moves through its status transitions until it reaches a terminal state. Typical transitions include: * Driver assigned * En route to pickup * Picked up * In transit * Delivered * Failed The Nash Portal provides scalable monitoring for thousands of concurrent jobs and is the recommended operational tool for live deliveries. For real-time, system-to-system updates, consume [webhooks](/reference/webhooks). When a delivery completes, proof of delivery may include photo confirmation, signature capture, or a barcode scan. Nash live operations

## The provider network Nash connects you to **80+ delivery providers** through one integration — from national on-demand fleets like Uber, Roadie, and Instacart to specialty and regional couriers. You can also bring **your own fleet** and manage it alongside third-party providers in one place. Because Nash competitively quotes across eligible providers and lets you negotiate contract pricing, you get coverage and price flexibility without integrating each provider yourself. You decide which providers are available to a given delivery through your [dispatch strategies](/reference/dispatch-strategies). ## Core building blocks These are the primitives you work with when integrating Nash. An **order** captures a potential delivery and produces quotes. Once dispatched to a provider, it becomes a **job** (delivery) that you track to completion. Reusable configurations that decide which provider fulfills a delivery — by lowest price, a preferred order of providers, or reliability — with auto-dispatch, fee caps, and failover settings. An automation engine that responds to events with filters and actions — applying a dispatch strategy, tagging or modifying orders, sending notifications, and more. Real-time event notifications (status updates, ETA changes, delays, proof of delivery) delivered to your endpoint so you can keep your systems and customers in sync. Live status and location for every delivery, available through the Portal, the API, and webhooks, with customizable tracking links for your end customers. Group multiple orders into efficient, constraint-aware [routes](/reference/routes) for your own fleet, then dispatch them. See [Route Optimization](/guides/route-optimization). ### How orders flow into a strategy Nash decides which dispatch strategy an order flows into automatically. See [Workflows](/reference/workflows) for how this decisioning is configured. ### Automatic failover If a provider fails — a driver cancels, no driver accepts, or an SLA breach becomes likely — a dispatch strategy can be configured to reassign the delivery automatically: Nash detects the failure or risk, fetches fresh quotes from the remaining providers, dispatches to the next best option, and continues tracking. This behavior is controlled by your dispatch strategy settings. ## Where Nash Agent fits Everything above runs on rules you configure. [Nash Agent](/nash-agent/overview) handles what rules can't: investigating a late delivery, recommending a strategy change, watching a risky order until it resolves. It acts with a confirmation step — scoped to your organization and your permissions.

Nash intervened — the moment a recommendation becomes an action. The agent docs cover how to control exactly when that's allowed.

} href="/nash-agent/overview"> What the copilot can see, what it can do, and what it asks first. } href="/nash-agent/guardrails"> Which actions run automatically — and which wait for your sign-off. ## Why teams use Nash The pattern across all of it: one integration, and the hard parts of delivery become configuration instead of code. * **Coverage without integrations.** On-demand, scheduled, multi-stop, and batched deliveries across 80+ providers and your own fleet — managed in one place. * **Cost under control.** Quotes are competitive by default; dispatch strategies pick by price, ETA, reliability, or your own blend, and Nash's volume helps on contract rates. * **Speed you can see.** Real-time courier and ETA visibility, route optimization for your fleet, and automatic failover when a provider falls through. * **Customers kept in the loop.** Live tracking pages and notifications that ride the same events your systems consume. ## Next steps Submit a delivery and retrieve provider quotes. Configure how Nash selects a provider for each delivery. Receive real-time delivery events on your endpoint. Explore the full API reference.