PUT
Upload a Snapshot Chunk
Chunk rows may contain new references or update known debts. A new valid reference with a positive remaining balance will create a debt attached to the campaign and its collection timeline. Uploading a chunk does not modify any debt yet: creations, updates, and omission reconciliation are applied after finalization and asynchronous processing of the complete snapshot.

Authentication and limits

Requires debts:write. Uses the write limiter: 500 requests/hour per company. Each body is limited to 10 MiB and each rows array to 20,000 rows.
string
required
Your campaign reference.
string
required
The same client-created snapshot reference used in the start request.
integer
required
Zero-based index. Send chunks strictly in order.
array
required
Rows following the snapshot row contract. Choose either invoice balances or account balances for the same receivables stream; see balance granularity.
Chunk rows use the exact same rows[].payment_plan contract as a one-request snapshot. See Send an external payment plan for activation, payment, cancellation, and idempotency rules.
GetBill stores a SHA-256 of the exact request-body bytes. An identical retry of an accepted index returns 200; changed JSON bytes return 409 chunk_content_conflict. An index greater than next_chunk_index returns 409 chunk_out_of_order. Rows across all chunks may not exceed the declared expected_row_count. Final validation also rejects duplicate effective identities or invoice references across chunks. A costly phone destination is validated asynchronously during processing after finalization. GetBill controls it per campaign, disabled by default; the partner cannot change it in a chunk, and the legacy accept_expensive_destination key is tolerated and ignored regardless of its value or JSON type. When the campaign does not allow it, its row remains part of the snapshot and completed status records a non-blocking warning in warnings, with warning_count and warnings_omitted; see Get Snapshot Status.