Skip to content

Guide

Reading large BUSY reports within the API limits

Standard read answers from the PC are at most 2 MiB, with up to 140 seconds of waiting. Write and streaming operations have their own limits in the operation reference. This guide covers standard reports.

Facts reviewed on

Page through long lists

  • Paged operations take page (from 1) and pageSize (usually up to 500, default 100). Read the report page by page instead of in one answer.
  • For registers, the summary and totals cover the whole range, not only the page, so you do not need every page to get the totals.
  • Page with a stable order: for custom SQL, add an ORDER BY, and keep page × pageSize within 100,000.

Ask for less at a time

  • Use a shorter date range, one customer or one item at a time.
  • Read one financial year per request unless you need several; a request carries at most 5.
  • Some operations have their own bound (for example at most 1,000 units per year) and answer 422 RESULT_TOO_LARGE beyond it.

Stay within the time limit

  • The PC has 120 seconds to run a read. One BUSY read runs at a time on the PC, so avoid firing many large reads at once.
  • On 504 RELAY_TIMEOUT or 429 RELAY_BUSY, wait for Retry-After, then retry a narrower request.
  • The credit-line stage stream is the exception: it streams one line per customer for up to 5 minutes and 64 MiB, ending with a done line.

Illustrative example

Illustrative example — not a customer case

A manufacturer wants a year of inventory daybooks. Instead of one request for the year, it asks month by month and merges the answers in its own system. Each answer stays well within 2 MiB and each read finishes quickly on the PC.