Tulip applies rate limits to table APIs to provide a consistent and reliable experience and to ensure high performance and availability on the Tulip platform. Rate limiting is being rolled out in stages across all Tulip instances during the spring of 2026.
Table rate limits
For Essentials, Professional, and Enterprise plans, the following rate limits apply per table within a workspace.
| API category | Rate limit value | Endpoints |
|---|---|---|
| Record write | 10 writes per second per table | POST /api/v3/tables/:tableId/records (createRecord) PUT /api/v3/tables/:tableId/records/:recordId (updateRecord) PATCH /api/v3/tables/:tableId/records/:recordId/increment (incrementRecord) |
| Record delete | 10 deletes per second per table | DELETE /api/v3/tables/:tableId/records (deleteRecords) DELETE /api/v3/tables/:tableId/records/:recordId (deleteRecord) |
| Record read (individual) | 50 reads per second per table | GET /api/v3/tables/:tableId/records/:recordId (getRecord) |
| Record read (multi) | 10 reads per second per table | GET /api/v3/tables/:tableId/runAggregation (runAggregation) GET /api/v3/tables/:tableId/records (listRecords) POST /api/v3/tables/:tableId/exportDataset (exportDataset) GET /api/v3/tables/:tableId/count (countRecords) |
NOTE: Some account plans will have custom configurations. This will be communicated to customers by Tulip Support or Customer Success Managers (CSM) when applicable. If you are unsure, please contact support@tulip.co
How is the limit counted?
Rate limits are enforced per (instance, table, operation). All API tokens on a single instance share the same bucket for a given table and operation — creating additional tokens does not increase the effective rate limit.
How will I know if I have reached the rate limit?
Notifications regarding table rate limits appear at the top of each table's page.
When you reach 80% of the rate limit, you will see the following warning banner:
When you have reached the rate limit, you will see the following error banner:
The warning/error banners reflect a rolling 7-day window. Once you hit the a threshold, the banner remains visible for up to 7 days after your usage drops back below the threshold. The banners will show a 'last exceeded' date to indicate when the threshold was last exceeded
What do I do if I exceed the rate limit?
- Review the 429 error. The table and token will help you identify why a given token is encountering rate limits.
- Batch requests if possible. For example, suppose you have an app that needs to fetch data for a set of table records. Instead of sending individual requests for each record, you’d want to send a single query that includes all the record IDs (or filtering criteria) you need—then process the results locally in the app.
- Cache results. Rather than sending frequent requests, cache the data from an earlier request. Then, either refresh the data when requested (such as when a user explicitly wants to refresh data in an app) or on a periodic basis that fits the rate limits.
- Make sure your script is correctly handling rate-limited requests. Make sure your script retries user requests after the 429 error.
NOTE: When calling an API via a connector function, the connector will automatically handle 429 responses, so no additional retry logic is required. External clients — scripts, automations hosted outside Tulip, or connectors calling Tulip's API from other platforms — must implement retry logic themselves.
Did you find what you were looking for?
You can also head to community.tulip.co to post your question or see if others have solved a similar topic!