Skip to main content
A store location is a physical origin — a restaurant, warehouse, or store — that deliveries depart from. Store locations let you register your pickup points once and then reference them from orders, associate them with zones, and answer coverage questions like “which of my stores serves this address?”

Modeling store locations

A store location describes a single origin and the information a driver and the dispatch system need to pick up from it. Create one with Create store location (POST /v1/store_locations). A store location can carry:
  • A name (the store’s business name) and a phone number — the two required fields
  • A first name and last name for the contact at the location
  • An email and pickup instructions for the courier
  • An address (as a single line) or pre-geocoded address components
  • An external ID that maps the location to your own systems
  • Free-form tags for your own classification
  • Operating hours and a prep time in minutes (both integration-specific)
  • Zone associations that link the location to one or more zones
Retrieve a single store location with Get store location (GET /v1/store_locations/{id}), or list them with Get store locations (GET /v1/store_locations). Update an existing location with PATCH /v1/store_locations/{id} and remove one with DELETE /v1/store_locations/{id}.
name and phoneNumber are the only required fields. If you don’t know the contact’s name, the API documentation suggests passing Manager for firstName and lastName.

External identifiers

Most teams already have their own identifier for each store. Rather than store and reconcile Nash’s IDs, you can address store locations by your external identifier and let Nash perform an idempotent upsert. Use Create or update store location by external identifier (POST /v1/store_locations/external-identifier/{externalIdentifier}). If a store location with that external identifier already exists, it is updated in place; if not, a new one is created. This makes it safe to replay the same request — for example when syncing your store catalog on a schedule — without creating duplicates. To read a location back by your own identifier, use Get store location by external identifier (GET /v1/store_locations/external_identifier/{externalIdentifier}).
There is also a plain upsert endpoint, Create or update store location (POST /v1/store_locations/upsert), and a bulk variant, Upsert multiple store locations (POST /v1/store_locations/upsert/bulk), for syncing many locations at once.

Coverage lookups

A coverage lookup answers “which store locations cover this point?” by testing a location against the delivery zones associated with your store locations. Use Get store locations that cover a specified latitude and longitude (GET /v1/store_locations/coverage). You can query by:
Provide both latitude and longitude to find the store locations whose zones cover that exact point.
GET /v1/store_locations/coverage?latitude=37.76&longitude=-122.43
latitude and longitude must be supplied together — if you pass one, you must pass the other.

Store locations vs. zones

Store locations and zones are distinct but related:
  • A store location is a physical origin that deliveries depart from.
  • A zone is a geographic area, defined by a polygon, where delivery is available.
You connect them through zone associations: associate a store location with one or more zones, and a coverage lookup can tell you whether a given dropoff point falls inside a store’s delivery area. The store location coverage endpoint returns the stores serving a point; the zones coverage endpoint returns the zones containing it.

Next steps

Create store location

Register a pickup origin and its contact details.

Upsert by external identifier

Create or update a store location idempotently by your own ID.

Coverage lookup

Find the stores that cover a latitude/longitude or city/zip.

Zones

Define the delivery areas your stores serve.