Re-link Invoice
Attaches, detaches, or moves the invoice’s parent link — the
invoice.relinked action. to names an event or a policy
({"type": "event" | "policy", "id": "<uuid>"}), or is null to detach.
The previous link (from) is recorded server-side from the current row —
clients never author it. A re-link posts zero ledger rows: money
follows the link at read time.
Precondition (422 LIVE_PAYMENTS). The invoice must have no live
payments — paid money has already eroded reserves where it landed; remove
the payments first (and re-record them after) to move a paid invoice. A
named target must exist (422 LINK_TARGET_MISSING).
Future recognition dates (422 FUTURE_DATE). An invoice whose
incurredDate is in the future can only be parented to a policy. Moving
it to an event, or detaching it, is rejected — change the recognition date
first.
movePayments — the paid-invoice composition. Opting in performs
that unwind automatically, in one transaction of enumerated actions:
every live payment mark is removed, the invoice re-links, and each mark
is re-recorded — amount, date, memo, and line item copied verbatim under
a fresh server-minted paymentId. journalIds returns every action in
execution order. The erode flag copies verbatim except: a reset-absorbed
payment re-records non-eroding; every re-record is non-eroding when the
destination is not an event; and erosion: "none" forces all re-records
non-eroding. With the default erosion: "preserve", eroding re-records
apply to the destination scope’s remaining reserve unbounded — a
signed balance: a shortfall takes the destination’s remaining reserve
negative — send erosion: "none" or set the destination’s estimate
first if that reading is not intended. A same-target re-link
never engages the composition — it keeps plain re-link semantics, so with
live payments it is 422 LIVE_PAYMENTS even with movePayments set.
Concurrency + idempotency. Requires If-Match (the invoice’s current
headJournalId) and a client-minted actionId (identical retry →
replay; different payload → 409 ACTION_ID_REUSED). The actionId
names the RE-LINK action — composition members are server-derived — and
the composition commits atomically, so a replayed retry returns the
re-link’s journal id plus refreshed state.
Required permission: company.payment:update
Authorizations
API key authentication. Send your raw API key as the Authorization header value with NO scheme prefix — Authorization: YOUR-API-KEY. Do NOT prefix it with Bearer or ApiKey, and do not use an X-API-Key header; those are not accepted.
Headers
The invoice's current headJournalId — the optimistic-concurrency watermark every single-invoice write after creation must send. Read it off any invoice read or write response and echo it verbatim (a bare uuid; an entity-tag dressing of it — "uuid" or W/"uuid" — is also accepted). Missing or malformed is a 400 (IF_MATCH_REQUIRED / IF_MATCH_INVALID); a stale value is a 409 IF_MATCH_CONFLICT whose body carries the current invoice. An idempotent actionId replay short-circuits BEFORE the watermark is evaluated.
Path Parameters
Company identifier
Invoice identifier
Body
Client-minted idempotency key — becomes the action's journal id. An identical retry replays the original outcome; reuse with a different payload is 409 ACTION_ID_REUSED
The new parent link — an event or a policy — or null to detach
Optional display label for the source system's author (e.g. the integrator-side user). Stamped as the journal record's display attribution; the acting principal stays the External API service user, so a label can never impersonate an in-app user. Ignored on idempotent replays
1 - 255Opt into the paid-invoice composition: remove every live payment, re-link, and re-record the payments against the new link, atomically. Omitted, a re-link with live payments is 422 LIVE_PAYMENTS
Response
The re-linked invoice — refreshed read state
The response of every single-invoice write — refreshed read state, not an ack: the emitted journal id(s), THE invoice row (identical shape to the reads — one invoice representation everywhere; its headJournalId is the next If-Match), and the invoice's live payments. An idempotent actionId replay returns this same shape rebuilt from the original outcome, server-minted values included.
Every journal id the write emitted — the anchor action's id (the actionId you supplied) first, then any engine-minted siblings (a multi-mark payment's additional marks) and any companion the horizon rule composed (e.g. the reserve unwind of a pre-horizon eroding payment's removal, or a delete's payment sweep)
1THE invoice representation — the same shape everywhere an endpoint returns an invoice (listing rows, the detail read, and every write's refreshed-row response). headJournalId is the invoice's current journal head — the optimistic-concurrency token subsequent writes echo back as If-Match.
The invoice's live payment marks after the write, newest first