---
title: "get customer"
method: GET
path: "/api/v1/sales/customers/{customer_id}"
tags: ["orders"]
---

# get customer

`GET /api/v1/sales/customers/{customer_id}`

## Request

- Base URL: `https://api.app.tightly.io`
- URL: `https://api.app.tightly.io/api/v1/sales/customers/{customer_id}`
- Auth: HTTP bearer

The person, their orders in the same row shape the Orders list serves, their returns, and what has been refunded to them across every channel they bought on. Call it to answer a question about a buyer; do not call it in a loop over a list, which is what the list itself is for. There is no write: a customer is created by the order writers and by the sync, never by this API.

`refund_status.refunded` is a money leg summed off the orders' own refunded amounts, which are the channel's figures and are never recomputed from lines. `cents` null with a reason beside it means no order of theirs has been refunded, which is absence and not a refund of nothing. `redacted_at` set means the identity was cleared on a channel's erasure event: the name, the email pseudonym and the domain are gone, and the orders, their lines and their figures were all kept.

Scope: `orders:read`.

## Path parameters

- `customer_id` string, required

## Headers

- `Tightly-Version` string

## Response `200`

The customer, their orders, their returns and what has been refunded.

- object
  - `data` object: the customer, orders, returns and refund_status.
  - `message` object: severity, service and desc.

## Other responses

- `400`: The path carries no customer id.
- `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 the record is not that account's (`account_mismatch`).
- `404`: No customer with that id is on file (`customer_not_on_file`).
- `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)