Propose line item
Counterparty proposes a draft AD_HOC LineItem on a non-FINALIZED LineItemGroup. The item lands in pending_line_item_ids with ad_hoc__status=PENDING; the owner resolves it via approve/deny. Caller must be on the LIG (origin or destination) but not the owner. | authz_personas=[lig_org_operators] | (LineItemClientCreate1) -> (LineItemGroup1)
Authentication
Bearer authentication of the form Bearer <token>, where token is your auth token.
Path parameters
Request
TODO - improve domain model notes here.
- unified catalog for all TG types and other services, e.g. IoT tracking devices
- some line items will match TG type more frequently
- …
Response
Must be a string starting with org_
Must be a URL-safe string of 1-64 characters. Allowed characters: A-Z, a-z, 0-9, ’.’, ’_’, ’~’, ’-’ (RFC 3986 unreserved).
Must be a string starting with org_
Must be a string starting with org_
LineItemGroup lifecycle.
The pre-FINALIZED window is a single STAGED state — operators compose the
bundle (add/remove owner ad-hoc into amendment, propose/approve/deny
counterparty items) and then call finalize/v1 to lock it. Every state
past STAGED is reached by a deliberate transition (finalize/v1,
open_invoice/v1, sync routes).
The legacy PENDING_RATES, PENDING_CALCULATION, and ADJUSTABLE states
were tied to the old auto-recalc-on-mutation hooks. Bucket amounts ARE
kept in sync on every mutation today (see the “Amounts” section of the
module docstring), but that’s a write-time invariant, not a status —
modeling “is the amount fresh?” as LIG status duplicates information and
was dropped 2026-05-03. The worklist principle (an empty
agreement_line_item_ids bucket or an unfilled
<vector>_line_item_group_id field IS the operator signal) makes the
intermediate states redundant in any case.
Must be a string starting with user_

