Ad-hoc add line item
Ad-hoc add line item
Appends an owner-direct AD_HOC LineItem to the amendment bucket of a LineItemGroup that has not yet been finalized. The agreement bucket is reserved for the original deal at creation; everything added after lands in amendment. | 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_

