---
title: "What is actually walking, the pending claims retailers have made against their book"
method: GET
path: "/api/v1/order-book/signals"
tags: ["order_book"]
---

# What is actually walking, the pending claims retailers have made against their book

`GET /api/v1/order-book/signals`

## Request

- Base URL: `https://api.app.tightly.io`
- URL: `https://api.app.tightly.io/api/v1/order-book/signals`
- Auth: HTTP bearer

The pending claims retailers have made against their book: one row per claim with the account, the line it names, the claim type, what the retailer wants, the line's current booked value and quantity, the source text it was read from, and when it was raised, with totals by type.

`season_code` is required; `commitment_id` and `as_of` narrow as elsewhere.

The money on each row is the brand's, not the retailer's: it is the line's current booked value, what is at stake if the claim is accepted, never a figure the retailer sent.

Only pending claims are counted. An approved signal has already been applied through the book's one writer, so counting it again would double the exposure, and an ignored one was judged not to be a change; both stay on file because the trail is the point. A claim naming no line is served and counted separately under `unsized_claims` rather than pooled into the money.

get_order_book_firmness says what can walk, classified from the term an account agreed to. This says which of it somebody has moved on. Recording or deciding a claim is not public.

Sold with Essentials+: without Tightly Connect the answer is 403 `plan_excludes`.

Scope: `order_book:read`.

## Query parameters

- `season_code` string, required
- `commitment_id` string
- `as_of` string, date-time

## Headers

- `Tightly-Version` string

## Response `200`

Every pending claim with the account, the line it names, what the retailer wants, the line's current value and, where it has none, the reason it cannot be sized; plus totals that keep the sized money and the unsized claims apart.

- object
  - `data` object
    - `as_of` string, date-time
    - `scope` object
    - `scope_reason` string, nullable
    - `signals` object[]: One row per pending claim, with the account, line_key, signal_type, the retailer's own words and what the retailer wants. `style` is the title of the garment the named line is (with its `product_id`), null where no line is named or the style has no title. `provenance` is email or portal; `raised_by_chair` is `buyer` for a claim the account's buyer typed in the portal and `brand` for one lifted from the account's mail; `raised_by` is the buyer's name on a portal claim and null on an email claim, which records no person.
    - `totals` object: pending, sized_value_usd over DISTINCT lines, sized_lines, unsized_claims and by_type.
  - `message` object: severity, service and desc.

## Other responses

- `400`: A required parameter is missing, or a date could not be read.
- `401`: No usable key: malformed, unknown, revoked, expired or stopped. One refusal covers all five, telling a caller which is which maps the surface for them. A request with no Authorization header at all is refused 400 before any key is looked for.
- `403`: The key may not reach this operation. `plan_excludes` when Order book is sold with Essentials+ and this organisation's plan does not include it; `scope_missing` when the key does not hold Order book; `organization_mismatch` when the path names an organisation that is not the key's; `ip_not_allowed` when the caller's address is outside the key's allowlist; `account_mismatch` when a key issued to one account calls this read, whose figure covers every account on the book; the sentence names `GET /order-book/account-styles` and `GET /order-book/account-anchor`, which are that account's own.
- `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)