Coverage and availability

We do not operate everywhere, and where we operate we do not always have a
vehicle free. Those are two different things, they fail differently, and knowing
which one you are looking at saves most of the debugging.

Coverage is structural. A location is either inside an operating area or
it is not, and that does not change minute to minute.
Availability is momentary. The area is covered, but right now there is no
suitable vehicle — because of demand, weather or the time of day.

A coverage problem will never fix itself by retrying. An availability problem
usually will.

Check the pickup point before you promise a delivery

The most common integration mistake is finding out at checkout. The customer
picks a product, enters an address, and only when the order is placed does the
API return an error. By then you have already taken the order.

Check first:

GET /v1/shipping_types/available?location=-34.577649,-58.41037

The location parameter is required and holds the coordinates of the pickup
point. A non-empty list means we operate there and your account has at least
one shipping type enabled for it — which is what you actually need to know
before taking an order. 404 means there is nothing available, usually a
location outside any operating area.

Coordinates are the input, and they are the reliable one: a text address has to
be geocoded first, and an address that is slightly wrong can geocode somewhere
plausible and wrong.

Use it when you onboard a merchant or a new store, not on every order. Coverage
does not change between two orders from the same shop.

What comes back

Which shipping types are available is per location, not per account: the same
credentials can see "Express" in one city and nothing in another. It is the same
"Express" either way -- one shipping type, one id -- so what this tells you is
whether it is active at these coordinates, not which id it has.

Send back the id you get, exactly as it came: it is an opaque value, and
its shape is not the same in every environment — sandbox returns readable names
such as express_default, production returns UUIDs. Do not parse it, derive it
or hard-code it, and do not carry one from sandbox into production.

An empty list for a location that you believe is covered is a strong sign that
the account has not been enabled operationally for that area, which is
something we have to do on our side.

Why creating a parcel succeeds and shipping it fails

POST /v1/parcels records a parcel. It does not check coverage, fleet or
pricing, so it succeeds for locations we cannot serve. The checks happen when
you ask for a price or a shipment:

Step	What it validates
`POST /v1/parcels`	The shape of the parcel. Nothing about where it is going.
`POST /v3/parcels/estimate`	Coverage, fleet, dimensions, pricing configuration.
`POST /v1/parcels/ship`	The same, again, at the moment of dispatch.

So a 200 from parcel creation followed by a 409 or 404 from estimate or
ship is expected behaviour, not an inconsistency. If you want to know whether a
delivery is possible, estimate it — creating the parcel tells you nothing.

Reading a coverage failure

Full text and causes are in API error messages.
The short version:

Message	It means
`outside operation area`	The point is not in any area we operate. Structural.
`no asset kinds available`	Covered, but no vehicle type is available for this route right now — or the account is not enabled for the area.
`pickup and dropoff are not in same region`	Both covered, but in regions a single parcel cannot cross.
`region not supported` / `country not supported`	The coordinates resolve outside our operation. Check they are not swapped.
`configuration missing`	Covered and available, but the shipping type is not configured for your account here. We have to fix it.

The one that trips people up is no asset kinds available, because it covers
both a momentary shortage and a permanently unconfigured account. Tell them
apart with the availability check: if GET /v1/shipping_types/available comes
back empty or 404 for that pickup point, no amount of retrying will help.

Boundaries

Operating areas are polygons, and a point near an edge can be outside it while
looking inside on a map. If a location that seems well within coverage is
rejected, check the exact coordinates you sent rather than the address you meant
— a geocoded address can land on the wrong side of a street.

From an agent

If you use an agent with our MCP server,
check_availability answers this in one call for a location, and
list_shipping_types shows what is enabled there. Neither quotes a price;
estimate_delivery does that.