Merge Payee
Repoints every non-deleted invoice linked to {payeeId} at toPayeeId,
in ONE transaction — the merge composition. Per linked invoice:
payment_removed ×k → payee_changed → payment_recorded ×k (invoices
without live payments take just the middle step). Re-recorded marks
copy amount / date / memo / line item / erode flag verbatim under NEW
server-minted payment ids — EXCEPT payments whose removal composed a
reserve unwind (reset-absorbed erosion), which re-record NON-eroding so
reserves are not eroded twice.
Idempotent by convergence. All member actions are server-derived (no
client actionIds, no If-Match): a retry finds nothing linked to the
merged payee and emits nothing (journalIds: []).
Selector vs target. {payeeId} is a pure selector — an id with no
linked invoices converges to an empty merge; toPayeeId must exist
(422 LINK_TARGET_MISSING) and must differ from {payeeId} (a
schema-level 400).
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.
Path Parameters
Company identifier
The payee being merged AWAY — a pure selector; every invoice linked to it is repointed
Body
The surviving payee every linked invoice is repointed to; must exist and differ from {payeeId}
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 - 255Response
Every emitted journal id, in execution order — empty on a converged retry (nothing left linked to the merged payee)
Every emitted journal id, in execution order
