API reference

Agreements & settlement

Account-level reads: your agreements, upfront pacing, and settlement paper. Buyers read /agreements and /settlement; sellers read the mirror at /me/settlement. Concepts: Agreements, Settlement.

List your agreements

GET/v1/agreementscatalog:read

Your active agreements: what each unlocks and how it settles. The full shape is the agreement object.

Query parameters

Field	Type	Description
`seller`	string	Filter to one counterparty.
`active`	boolean	Only agreements whose effective window covers today. Default: `true`.

Response

200 Response
{
  "agreements": [
    {
      "agreement_id": "agr_71c0d2",
      "buyer": "yourco",
      "seller": "acme",
      "catalog_scope": ["open", "private"],
      "rate_card_refs": ["acme-yourco-2026q4"],
      "permitted_buy_types": ["preemptible", "non_preemptible", "fixed_position", "audience_guaranteed"],
      "settlement_mode": "direct",
      "effective": {
        "start": "2026-10-01",
        "end": "2027-09-30"
      }
    }
  ]
}

Read and write your presented identity

GET/v1/agreements/{id}/identitycatalog:read

PUT/v1/agreements/{id}/identityorders:write

What you are called at this seller. One agency is one organization on the platform, but each seller knows it by its own display name and its own code: an intake that requires AGY-9 is not served by a global identifier. So the fact lives on the agreement, which is already the object that holds one buyer and one seller.

The one block on an agreement you write. The seller authors the grant, the terms, and its own external_ref; you author this, and both sides read it. A seller credential is 403 here. Unset means your organization's own name and ids stand, which is the right default when nothing differs.

Fields

Field	Type	Description
`name`	string	The display name you present to this seller. The local office rather than the holding company, where that is what the paper says.
`id`	string	The code the two of you transact under on the seller's paper. Opaque to the platform, never validated. This is the field an intake calling for an `agency_id` is asking for.
`external_ref`	string	Your own system-of-record code for this relationship. Same contract as `external_ref` on the registries.

Full replace. The body is the whole block: a PUT stating one field leaves the others unset, and {} clears it. An unknown field is 422 INVALID_INPUT naming it rather than silently dropped, because adapters fill partner intake fields from this and a discarded key is data loss.

An agreement that is not yours, and an id that names no agreement, both answer 404 in the same words. Which sellers you transact with is not something another buyer can learn by asking.

{
  "agreement_id": "agr_acme_demo",
  "seller": "acme",
  "buyer": "yourco",
  "buyer_identity": {
    "name": "Yourco Media, Northeast",
    "id": "AGY-9",
    "external_ref": "YOURCO-REL-ACME-01"
  }
}

Read upfront pacing

GET/v1/agreements/{id}/pacingcatalog:read

Commitment drawdown on an upfront agreement: what you committed, what you have booked, and whether you are on pace. See Upfront.

Response

200 Response
{
  "agreement_id": "agr_71c0d2",
  "commitment_gross": 2400000,
  "currency": "USD",
  "booked_gross": 1350000,
  "pace": 0.96,
  "quarters": [
    {
      "quarter": "2026-Q4",
      "committed": 800000,
      "booked": 610000,
      "remaining": 190000
    }
  ]
}

remaining is derived, always exactly committed - booked, carried for the reader's convenience and never a second fact: a disagreement between the three is impossible by construction, and committed and booked are the authoritative pair.

Errors

Status	Code	When
404	`NOT_FOUND`	No such agreement in your scope, or the agreement carries no upfront commitment.

List invoices (buyer)

GET/v1/settlement/invoicessettlement:read

Invoices on your cleared trades. Direct-settled orders never appear here: on direct, you invoice each other and the platform carries only the paper trail. See Settlement.

Query parameters

Field	Type	Description
`order`	string	Filter to one order.
`period`	string	Broadcast-calendar billing period, for example `2026-11`.
`status`	enum	`open`, `paid`, `credited`.

Response

200 Response
{
  "invoices": [
    {
      "invoice_id": "inv_20c4a1",
      "order_id": "ord_9f3a12c4b7e1",
      "external_order_id": "q4-campaign-042",
      "estimate_id": "EST-4402",
      "period": "2026-11",
      "gross": 8100.00,
      "currency": "USD",
      "status": "open",
      "issued_at": "2026-11-30T00:00:00Z"
    }
  ]
}

Invoices cross-reference your external_order_id and the estimate_id from buyer_metadata, so your billing system can match the record.

Read your credit position

GET/v1/settlement/creditsettlement:read

Current limit and exposure on cleared trading. A cleared order that would breach the cap fails fast at create with CREDIT_LIMIT; see Errors. Credit is per agreement, and this endpoint is where it lives: exposure is a live number that gates order creation, so it has one authoritative surface, this one, rather than also riding inside the slow-moving agreement object clients reasonably cache. The agreement carries no credit block.

Query parameters

Field	Type	Description
`agreement` required	string	The agreement whose credit position to read, e.g. `?agreement=agr_71c0d2`. You must be a party to it: a buyer credential may name only agreements whose `buyer` is its own tenant, a seller credential (on the mirror read) only agreements whose `seller` is. Credit limit and exposure are commercially sensitive, so the boundary is fail-closed and non-enumerable, the same posture cross-tenant order reads and foreign upload ids take: an agreement that does not exist, one you are not a party to, and a `direct` one (which has no credit position) all return the identical `404 NOT_FOUND`, so a known agreement id never confirms whose it is or how it settles.

Response

200 Response
{
  "agreement_id": "agr_71c0d2",
  "currency": "USD",
  "credit_limit": 500000,
  "exposure": 121500,
  "available": 378500,
  "as_of": "2026-10-02T14:00:00Z"
}

available is derived, always exactly credit_limit - exposure: the two authoritative figures are the limit and the live exposure, and the difference is carried so a client never recomputes it wrong. It is the number the CREDIT_LIMIT fail-fast compares an order's gross against.

List invoices (seller)

GET/v1/me/settlement/invoicessettlement:read

The seller mirror: outbound invoices on your cleared trades, with the same query parameters and shape as the buyer read. Make-good credits link back to the buyer credit they mirror, so the ledger stays back-to-back by construction.

Response

200 Response
{
  "invoices": [
    {
      "invoice_id": "inv_20c4a1",
      "order_id": "ord_9f3a12c4b7e1",
      "period": "2026-11",
      "gross": 8100.00,
      "currency": "USD",
      "status": "open",
      "make_good_ref": null
    }
  ]
}