Working with Data Export API response limits

What the limits are

Two kinds of limits apply to requests that include a date range:

Maximum date range

If the time between startDateTime and endDateTime exceeds seven days, the API returns a 400 response with the error code ERR_DATE_RANGE_EXCEEDED. Reduce the size of the requested time window and submit the request again.

Maximum response size

The maximum supported size of a response file is 6MB, which should be large enough to hold the data for nearly 10,000 jobs. If the data that matches a request would exceed the maximum response size, the API returns a 413 response with the error code ERR_RESPONSE_LIMIT_EXCEEDED. The response body includes a maxJobs value that indicates the limit in effect. To recover, narrow the date range, request fewer printers, or both, and submit the request again.

Planning requests to stay within the limits

To design an integration that reliably stays within the response limits, consider the following factors:

• Job volume per printer. A high-throughput continuous-feed printer can produce many more jobs per hour than a low-volume cut-sheet printer. If you mix both in your fleet, the high-volume printers determine how short your time windows must be.
• Number of printers per request. Each request can include multiple printerId values. Combining many printers into a single request is convenient, but every additional printer increases the response size and the chance of exceeding the limit.
• Time of day. If your operation runs in shifts, jobs and state changes are concentrated in certain hours. A 24-hour window can return very different volumes depending on when those 24 hours start and end.
• Tolerance for retries. If a request fails with ERR_RESPONSE_LIMIT_EXCEEDED, your integration must split the request and retry. Designing for smaller windows up front is usually less complex than implementing dynamic splitting.

Recommended patterns

The following patterns work well for common integration scenarios:

Nightly extract for reporting

Run a scheduled job once per day that requests the previous 24 hours of data, one printer at a time. This pattern is simple to implement, easy to retry on failure, and keeps each response small. Combine the per-printer responses in your downstream process.

Hourly extract for near-real-time dashboards

Run a scheduled job once per hour that requests the previous hour of data for all printers in a single call. Hourly windows keep response sizes small even for high-volume printers. If your fleet is large, request printers in groups rather than all at once.

Backfill of historical data

To populate a data warehouse with historical data, iterate over the time range in fixed-size windows (for example, six hours per request) and over your printers in small groups. Process one window at a time and store the results before moving to the next window. If a window fails with ERR_RESPONSE_LIMIT_EXCEEDED, split that window in half and retry the two halves.

Current printer state for monitoring

To monitor the current state of every printer in your fleet without retrieving history, call /printer-states with currentState=true. The response includes one row per engine and is not affected by the date range, so a single request can cover the entire fleet.

Handling response-limit errors in your integration

When you receive a 413 response with ERR_RESPONSE_LIMIT_EXCEEDED, take one or more of the following actions before retrying the request:

• Reduce the time window. Splitting the window in half is a reliable strategy; if the halved request still fails, split again.
• Reduce the number of printerId values in the request. If one printer is responsible for most of the volume, request that printer separately.
• If the request is for a current snapshot rather than a history, use currentState=true on /printer-states to avoid date-range-driven volume entirely.

Do not retry the same request without changing parameters. The API does not return partial results, so an unchanged retry will fail again.