Limits by plan
| Plan | Analyses / 60s | Reads / 60s | Writes / 60s |
|---|---|---|---|
| Free | 5 | 60 | 20 |
| Starter | 10 | 120 | 40 |
| Growth | 30 | 300 | 80 |
| Pro | 60 | 600 | 150 |
| Scale | 150 | 1,200 | 300 |
POST /api/v1/analyses and POST /api/v1/analyses/batch (each image in a batch counts as one analysis request).
Reads — All GET endpoints (analyses, products, tasks, places, reports, usage).
Writes — All POST and PATCH endpoints except analysis submission (tasks, places, inventory, webhooks).
Rate limit headers
Every API response includes headers showing your current rate limit status:| Header | Description |
|---|---|
X-RateLimit-Limit | Maximum requests allowed in the current window |
X-RateLimit-Remaining | Requests remaining in the current window |
X-RateLimit-Reset | Unix timestamp (seconds) when the window resets |
Handling rate limits
When you exceed the rate limit, the API returns a429 Too Many Requests response with a Retry-After header indicating how many seconds to wait:
Best practices
Exponential backoff
When you receive a
429, wait for the duration specified in Retry-After, then retry. If the retry also fails, double the wait time on each subsequent attempt.Use batch endpoints
Submit up to 20 images in a single batch request instead of making 20 individual calls. This consumes only 1 rate limit slot for writes.
Cache results
Analysis results are permanent. Cache responses locally to avoid redundant
GET requests.Use webhooks
Instead of polling for analysis status, register a webhook to receive notifications when analyses complete. This eliminates repeated
GET requests.