Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.trueparser.com/llms.txt

Use this file to discover all available pages before exploring further.

Overview

TrueParser applies plan-based limits to keep parsing traffic predictable and fair across a tenant. These limits are enforced across the tenant and apply to all apps attached to that tenant.

Important

Tenants that need higher throughput or more concurrency should consider dedicated deployments or on-premise deployments. Contact us here.
Depending on your plan, limits can be applied over multiple usage windows that reset over time. The exact values are plan-specific and are not exposed in this document.

Request Limits

TrueParser enforces request limits for API traffic. At a high level:
  • request limits are enforced per app and tenant context
  • limits are shared across the tenant’s parsing traffic
  • if an app sends too many requests too quickly, the API may return 429 Too Many Requests

Upload Protections

TrueParser also applies upload protections to keep bursty traffic from overwhelming the platform. These protections help balance:
  • queue depth
  • concurrency
  • request bursts
  • upload bandwidth
At the product level, tenants are protected by resource guards that limit how much work can be accepted at once. We do not expose the internal enforcement details, but the platform uses these controls together with plan-based limits to keep upload behavior fair.

Plan-Based Usage Windows

In addition to upload limits, TrueParser plans may include usage windows that reset over time. The exact combination of windows depends on the plan you are on. A good starting point is:
  • plan-based limits set according to your tenant tier
  • upload protections enabled by default
  • conservative client-side retry and backoff behavior
This gives enough headroom for mixed traffic while still keeping upload pressure under control.

Notes

  • Limits are tenant-scoped.
  • All apps for the same tenant share the same limits.
  • Tenant plans may include caps on concurrent uploads, request rate, queue depth, and upload bandwidth.
  • The exact values can be tuned later as workloads change.
  • If a request exceeds a limit or the system is under pressure, the platform returns 429 Too Many Requests.
  • If you send too many requests too quickly, expect the platform to protect itself by refusing additional work until pressure drops.
If the platform is temporarily overloaded, it may also return 503 Service Unavailable, and you should retry with backoff when appropriate.
Last modified on April 28, 2026