Batching and filters¶
Why batching exists¶
List endpoints return at most 100 entities per response. To export or sync an entire dataset you must walk batches with cursors.
Common query parameters¶
These parameters apply to most collection list endpoints (/companies,
/debtors, /documents, /general-log-entries, and others):
| Name | Required | Description |
|---|---|---|
companyId |
No | Limit results to one company. Ignored when cursor is set. Discover IDs via GET /companies. |
modifiedSince |
No | RFC 3339 timestamp. Returns entities modified at or after this time. Ignored when cursor is set. |
cursor |
No | Opaque cursor from a previous response (next_batch_cursor or resume_cursor). When set, companyId and modifiedSince are ignored. |
Example¶
curl -X GET 'https://{your-collections-platform-host}/api/v1/debtors?companyId=1&modifiedSince=2024-01-01T00:00:00%2B00:00' \
-H 'accept: application/json' \
-H 'Authorization: Bearer <token>'
Response envelope¶
{
"data": [ { "...entity..." } ],
"next_batch_url": "https://…/api/v1/debtors?cursor=…",
"next_batch_cursor": "…",
"resume_url": null,
"resume_cursor": null
}
Incremental full export¶
- Call the endpoint (optionally with
companyId/modifiedSince). - Process
data. - If
next_batch_cursoris non-empty, call again with?cursor={next_batch_cursor}. - Repeat until
next_batch_cursoris empty. - Store
resume_cursorwhen present. Later, pass it ascursorto fetch only changes since that point.
Race window¶
modifiedSince cannot be more recent than 600 seconds ago. To get the newest
data, use a modifiedSince at least 10 minutes in the past and walk all batches.
Due to concurrent writes you may see entities you already received; you will not
miss changes in the window.
Company division¶
In BT Collections a company is a group of debtors; each debtor belongs to exactly
one company. Many calls are scoped by companyId. Start with GET /companies to
list companies your token can access, then loop per company if you need a full
export.