Invoice webhooks (V2)

Create an invoice webhook registration through /api/v2/management/webhook-registrations/. Its payload uses the same invoice representation as /api/v2/management/invoices/{id}/, without expansions. Invoice identifiers are UUIDs.

Event	Trigger
invoice.created	An invoice is inserted.
invoice.updated	An invoice is updated, or one of its line items is inserted, updated, or deleted.

Moving a line item to another invoice notifies both invoices. Each notification belongs to the company that issued that invoice, even when its client or a line item's cached company field belongs to another company.

Each delivery attempt reads the invoice's current state, including its line items. The payload is not a snapshot of the invoice when the change occurred. Retries can therefore contain newer state. A transaction that changes several rows can produce several notifications; consumers should synchronize by invoice ID and handle duplicate delivery identities.

Renaming what a line sells, such as a product or a class pass, changes that line's description and produces invoice.updated for every invoice that bills it. Changing a company's currency does not by itself produce an invoice notification; the next invoice or line-item notification includes the then-current representation. Deleting an invoice does not emit an invoice.deleted event; a pending notification whose invoice no longer exists is discarded.

Payment, finalization, and refund flows produce invoice.updated when they update the invoice. This event does not mean that payment succeeded. Read status, paid_amount, and outstanding_amount from the payload instead of treating every update as a payment transition. Detect invoice lifecycle steps shows the change that marks each step.

Existing Backoffice invoice webhooks retain their separate lifecycle events and payloads. Existing Public API V1 registrations cannot subscribe to the new invoice events.