Base64 content
content
The file content of the uploaded document, Base64-encoded. A single call accepts at
most 5 items.
"content": "JVBERi0xLjcK..."
Page number
page
The number of the requested page in page-numbered lists (starting at 1). Only four
lists use it: GET /1/expenses/, GET /1/incomes/, GET /1/partners/ and
GET /1/accounts/. Every other paginated endpoint is cursor-based — there is no
page there, and you walk it by following the next link (see cursor).
?page=2
Page size
page_size
The number of items returned per page. A larger value means fewer requests but a
slower response; 50–200 is usually optimal.
?page_size=100
Pagination cursor
cursor
The opaque pointer used by the cursor-paginated lists, carried in the response's
next / previous link. Not a /2/ thing: five /1/ lists page this way too
(documents, documents/files, tax-codes, monthly-salaries,
monthly-taxes). Follow it verbatim: the value is not meant to be constructed or
decoded, and nothing should depend on its internal structure.
?cursor=cD0yMDI2LTA4LTAxKzEwJTNBMTIlM0EwMA%3D%3D
Result list
results
The field holding the data of a paginated response; together with next /
previous it forms the pagination envelope. On most lists it is an array. On five
of them it is an object instead — GET /1/expenses/, GET /1/incomes/,
GET /2/expenses/, GET /2/monthly-salaries/ and GET /2/monthly-taxes/ — where
the paginated records sit under their own key (expenses, incomes,
monthly_salaries, monthly_taxes), alongside the reference lists needed to
resolve their ids. count is present only on the page-numbered lists, not on the
cursor-based ones.
"results": [ { "id": 90231 } ]