---
title: "send shipping notice"
method: POST
path: "/api/v1/sales/orders/{order_id}/shipping-notice"
tags: ["orders"]
---

# send shipping notice

`POST /api/v1/sales/orders/{order_id}/shipping-notice`

## Request

- Base URL: `https://api.app.tightly.io`
- URL: `https://api.app.tightly.io/api/v1/sales/orders/{order_id}/shipping-notice`
- Auth: HTTP bearer

Sends the account an 856 shipping notice built from what the warehouse actually shipped: the cartons, the barcode on each, the carrier and the tracking number. Call it once the warehouse has confirmed the shipment. It is refused where the warehouse reported no cartons, because a notice with a guessed pack structure is what a retailer receives against and charges you for; type the carton list against the shipment first.

The notice's state under `shipments[].shipping_notice` moves `queued` to `sent`, or to `failed` with the network's own sentence on it, and a retry re-sends that document rather than creating a second one.

Do not call it for accounts that do not take shipping notices over EDI, and do not call it twice for one shipment.

Scope: `orders:write`, which includes `orders:read`.

## Path parameters

- `order_id` string, required

## Headers

- `Tightly-Version` string
- `Idempotency-Key` string

## Response `200`

The order, with the notice's state on its shipment.

## Other responses

- `401`: No usable key: malformed, unknown, revoked, expired or stopped.
- `403`: The key does not hold Orders (`scope_missing`), or the organisation's plan does not include wholesale, or the key is issued to one account and the order is another's (`account_mismatch`).
- `404`: No order with that id is on file.
- `409`: `order_is_not_an_accounts` (the order belongs to no account), `partner_takes_no_856` (the account does not take one, or nobody has asked), `nothing_shipped_to_notify`, `shipment_without_cartons`, `cartons_exceed_what_shipped`, `partner_not_connected`.
- `429`: The key has spent its allowance for this minute. 600 reads and 120 writes a minute, counted per key, refused calls included. `Retry-After` says how long to wait.
- `503`: The database is briefly out of reach, which is what a failover or a full connection pool looks like from outside. Wait the seconds `Retry-After` names and send the request again. A read is safe to repeat. A write is not, because the connection was lost in the middle of it, so read the object back before sending it a second time. Branch on the status rather than on `code`, which is `POSTGRES_UNAVAILABLE` from one of the two seams that raise this and `SERVICE_UNAVAILABLE` from the other.

---

[API](https://skmtc.dev/tightly/apis/tightly-api.md) · [All operations](https://skmtc.dev/tightly/apis/tightly-api/llms.txt) · [OpenAPI document](https://skmtc.dev/tightly/apis/tightly-api/revisions/199f7eb35afb?raw)