---
title: "list invoices"
method: GET
path: "/api/v1/sales/invoices"
tags: ["orders"]
---

# list invoices

`GET /api/v1/sales/invoices`

## Request

- Base URL: `https://api.app.tightly.io`
- URL: `https://api.app.tightly.io/api/v1/sales/invoices`
- Auth: HTTP bearer

The wholesale invoices Tightly has raised, newest first, with what the books did with each and what the network did with its 810. Use it to reconcile your accounts receivable against what shipped. It does not include consumer orders: a storefront's own payment is not an invoice Tightly raises.

Scope: `orders:read`.

## Query parameters

- `trading_partner_id` string
- `state` 'draft' | 'issued' | 'voided'
- `order_id` string
- `offset` integer
- `limit` integer

## Headers

- `Tightly-Version` string

## Response `200`

The invoices, newest first.

## Other responses

- `400`: An offset or limit outside the bounds every list keeps.
- `401`: No usable key: malformed, unknown, revoked, expired or stopped.
- `403`: The key does not hold Orders (`scope_missing`), or is issued to one account and named another (`account_mismatch`).
- `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)
