We’re rolling out rate limiting for the Tulip Tables API. This post explains what’s changing, the timeline, and what you need to know.
NOTE: This does not apply to customer instances on the LTS release cycle. There will be separate communications for these customers in the Spring/Summer.
What’s changing?
Tulip is introducing rate limits on Tables API requests made via API tokens. This ensures consistent performance for all customers. Rate limits apply per table, per instance to the following operations:
Operation
Limit
Record read (single)
50 requests/sec
Record read (multi — counts, aggregates, list reads)
10 requests/sec
Record write
10 requests/sec
Record delete
10 requests/sec
What’s affected: Any Tables API request authenticated with an API token, whether called from an external system or from within Tulip.
What’s not affected: Built-in table operations in apps (e.g., table records widgets, trigger actions that read/write records), player activity, and internal automations that don’t use API tokens are not subject to these limits.
What’s the timeline?
Today: Grace period begins
If your usage exceeds the thresholds, you’ll see warning and error banners on the Tables page
No requests will be rejected during this period — this is visibility only
April 15, 2026: Enforcement begins
Requests exceeding the limits will receive an HTTP 429 (Too Many Requests) response
The grace period gives you time to review and adjust your usage before enforcement begins
Am I affected?
The majority of customers are operating well below these limits and will see no change. If you are affected, you’ll see banners on your Tables page during the grace period – examples below:
Review the banners on your Tables page to identify which tables and operations are exceeding limits
Look at your API integrations — common optimizations include reducing polling frequency and adding caching
Contact your CSM or Tulip Support if you need guidance
What if I need more time?
If you’re affected and need more time to adjust, reach out to your CSM or Tulip Support before April 15. We will work with you to understand your use case and the available options, and can extend the grace period while we do so.
We have many tables and API tokens in our instance. I cannot go through each Tables every day to find out whether rate limit warning/error is occurring.
Please prepare the UI so that we can easily see
Name and ID of the Tables which the Rate limit warning/error is occurring
Exact date and time of when that Rate limit warning/error started happening.
Name and ID of the API token which is causing the Rate limit warning/error
@ta-aoki We understand and will be continually working to give you the right amount of visibility into your usage. As we roll this out we will be working very closely with customers that are near or at the limits. In these cases (like yourself) we will reach out directly to summarize your usage and review options. We do plan on adding the details you mention to the platform as well.
Thanks for the feedback, we working to reduce the negative impacts of rolling out rate limits, but there are cases like you describe that do highlight some issues. To mitigate this, we are monitoring use cases like this and are willing to work with you to better understand the options. We are also will be looking at how we can make these errors more actionable in automations.
The Automations and Functions do have a loop, where you can call connector functions.
You should provide a functionality on the loop block “set rate limit” and provide the option to choose a custom one or set it to “10/s for Tables API”.
When you set limitations, the platform itself should be able to handle them.
11 new entries, could already fail (when they are written within a second).
@danielpomeranz We don’t want to discourage the use of the API - this is intended to help balance the demand so all customers can benefit from a more responsive and predictable platform (standard practice for many SaaS platforms). You should be able to keep doing what you are doing, but at a slower rate. If a higher rate is important for you, I’d be interested in hearing more about the use case.
@pete I have similar concerns. A few of our tables have been created and integrated into 500+ applications, so if changes to table read/write behavior are needed, this could require an immense application architecture change. Can you please share usage metrics and review options with us as well? Thanks! (@Joelle for visibility)
Should the warnings be visible yet? Pretty sure we should be seeing some warning on some of our tables but im not seeing anything yet. Even manually tried spamming the API more than 10 times per second on record updates and have not yet seen an error pop up.
Similar situation as above. Not seeing the banner as I clearly ran a listRecords job exceeding the 10 reads/second/table limit.
If I remember correctly, before this update it was 50 read/s/table for listRecords (/:tableId/records). Our integration service was built around this limit. So either the banner is not working, or we need further clarification on the limit before modifying our integrations.
@chris.wartella The rollout has started, but will take a few weeks based on deploy groups. If you would like to see your usage before that, contact your CSM or Support and they can provide you with the details.
@thorsten.langner I understand this is a little misleading so to clarify:
most customers are not affected by this change as their usage is well below these limits. This is why we chose the mid April date.
some power users are already near or over the proposed limits. We have identified these customers and are working directly with them in many cases to find the best path forward. In these cases we are willing to extend the grace period if necessary.
I believe we may be working with your team already, but please reach out to your CSM need more details about your specific usage.
