PUT
Submit a Snapshot
This is a complete snapshot. After asynchronous processing, every active campaign debt omitted from rows is treated as settled.
The scope is not fixed. After successful asynchronous processing, a new valid reference with a positive remaining balance creates a debt, attaches it to the campaign, and adds it to the configured collection timeline.

Authentication and limits

Requires debts:write. Uses the batch limiter: 50 requests/hour per authenticated company. The body must be at most 10 MiB and contain at most 20,000 rows.
string
required
Your campaign reference.
string
required
Your client-created, stable reference for this complete logical snapshot. Use an immutable export ID or UUID; do not use a date alone. Generate a reference. Reuse it only to retry the same content.
array
required
Complete snapshot rows. Choose the balance granularity before sending rows.
The body contains rows. Its accepted fields are defined in the snapshot row contract; other fields are rejected, except that the legacy accept_expensive_destination key is tolerated and ignored regardless of its value or JSON type.
A row may include a payment_plan object to send every installment of a plan in one operation. See Send an external payment plan for activation, cancellation, and idempotency rules. Use invoice_reference for one invoice balance per row, or internal_id for one account balance per row, as described in the guide. The snapshot itself communicates balance changes; do not send payment events separately. When both are included, internal_id supplies the primary identity, and invoice_reference is also validated and must not belong to another debt; integrations should normally send only their chosen representation.

Balance and payment-plan behavior

The last accepted API call wins. remaining_amount is the current unpaid balance, whether it moves down or up. A present payment_plan replaces any active plan local to that debt when the total of its pending installments matches remaining_amount. A mismatch returns invalid_snapshot_row on the payment_plan field. Omitting payment_plan keeps the active local payment plan unchanged. Every installment with status set to paid requires paid_at and an external_payment_id that is unique for the authenticated integration and debt. The fields snapshot_at, allocations, financial_operations, coverage, and covered_remaining_amount are not accepted. Request receipt time provides the audit chronology.
Poll status_url; 202 does not mean processing is complete. Costly phone destinations follow the GetBill campaign configuration, which defaults to disabled and cannot be changed by the partner request. They are reported after asynchronous processing in the status resource as non-blocking warnings; they do not reject the complete snapshot or remove a row from full_sync reconciliation. See Get Snapshot Status.

Idempotent retry

After a timeout, retry the exact request-body bytes. GetBill compares the delivery mode and a server-computed SHA-256 of the raw body. JSON with different whitespace or key order conflicts even when it decodes to the same data. An identical retry returns 202 while pending/processing or 200 with an existing completed/failed result. It never applies reconciliation twice. Changed content returns 409 snapshot_reference_conflict; switching to staged delivery returns 409 snapshot_delivery_mode_conflict.