API Limits

---

Job Concurrency Limits

Our system runs different types of jobs, but the main ones are validation, training, and prediction. These jobs use shared compute resources, so to keep things fair and stable for all partners, we set capacity limits for them. We enforce these limits with concurrency ceilings at two levels:

1. Per-dataset – caps the number of simultaneous jobs that a single dataset can run.
2. Per-integrator – prevents any one integrator from monopolising global capacity.

Per-Integrator Limits

• Ensures one integrator cannot monopolize compute resources.
• Applies across all datasets managed by the same integrator.

Per-Dataset Limits

Contraint that caps the number of simultaneous jobs that a single dataset can run. The constraint depend on the type of job that is running. See limits below:

📤 Data upload

Uploaded data triggers a validation job with limited concurrency. We allow up to 5 concurrent validation jobs per dataset. To avoid hitting concurrency limits, batch validation requests and distribute them over time. Avoid sending too many validation jobs at once, especially after large data uploads. See recommendations below on how to batch large datasets.

🏗️ Training

Training jobs are especially resource-intensive, and running multiple for the same dataset simultaneously leads to unnecessary and redundant processing. To prevent this, only one training job per dataset is allowed at a time. We recommend queuing or spacing out training requests, especially after large data uploads or wage runs.

🎯 Prediction

Prediction job limits are dynamic and depend both on the number of concurrent jobs per dataset and your integrators total active job count. Avoid large bursts of prediction requests. Implement retries and back-off strategies as needed.

Best Practices

• Batch and stagger job submissions (e.g. schedule jobs per 5th minute).
• Implement retry logic for handling capacity-related rejections
• Queue jobs strategically to avoid overlapping executions.

Throttling Limits

For partners integrating with our API, especially when managing scheduled jobs or batch data uploads, efficient use of the get_status endpoint is key to maintaining throughput and avoiding request throttling.

Click here for more information

Our infrastructure supports up to 2000 requests per unique IP address within a rolling 5-minute window. This rate limit is enforced globally, not per customer/dataset, and is designed to ensure system stability and fairness across all integrations. The throttling is also enforced on all endpoints, meaning that if an IP address is throttled for extensive usage of the get_status endpoint, the same IP address will not be able to trigger jobs on other endpoints (start_trainer, etc.).

Request Rate Limit

• Maximum of 2,000 requests per IP address in a rolling 5-minute window.
• This is a global limit and applies to all endpoints.

Best Practices

• Reduce polling frequency, especially on /get_status.
• Stagger job start times across customers.
• Use webhooks instead of polling whenever possible.

---

Payload Constraints

Maximum data upload

Each file uploaded via the presigned URL can be up to 5GB. To avoid infrastructure limits, split large uploads into batches. Minimize the number of jobs by batching sensibly. See suggestion for batching sizes below.

Click here for more information

When data is uploaded, a validation job checks its structure and integrity. Validation jobs have limited concurrency, and integrators should avoid initiating too many jobs at once for the same dataset. For large data uploads, integrators should split their payload into batches to avoid infrastructure limitations and speed up validation. Each file uploaded via the presigned URL can be up to 5GB.

If a larger number of validation jobs is required than we allow with the job concurrency limit, preferably use our webhooks solution to start new jobs when previous jobs finish.

Batching the data helps mitigate capacity issues and reduces validation time. However, we advise the integrator to attempt to keep the number of upload/validation jobs to a minimum, therefore we recommend the following.

Recommended Batch Sizes

Employee	Recommended Batches
< 5,000	1 batch
3,000-5,000	2 batches
>5,000	4 batches

Maximum payload size in prediction requests

For larger payloads we recommend using presigned_url. However, the create_prediction endpoint can also be used for larger payloads, but has a capacity of 6MB. If this is exceeded you will receive the following errors:

• Payloads over 6 MB result in a 413 Request Too Long error.
• Hard limit at 10 MB → 413 Content Length Exceeded.