We are excited to announce that SeaTable Cloud version 5.3 is just around the corner, with an expected release in mid-June 2025. This update brings two important changes that may affect how you interact with our API.
1. Removal of /dtable-db and /dtable-server endpoints
As previously announced in February 2025 (see details here), the deprecated /dtable-db and /dtable-server API endpoints will be permanently removed in version 5.3.
What does this mean for you?
All API requests must now use the SeaTable API Gateway.
If you have developed custom solutions using the SeaTable API, please check your code to ensure you are not relying on the deprecated endpoints.
No action is required if you are using the latest versions of n8n, Make, Zapier, or standard Python/JavaScript integrations within SeaTable.
2. Introduction of Team API Limits
As first announced in 2024 (see announcement), we will introduce team-based API usage limits with version 5.3.
Why are we making this change?
This step is necessary to ensure fair and reliable service for all users, as some teams have generated extremely high API traffic that we could not previously limit.
API limits will be set monthly, based on your subscription level and team size.
Good news: Over 95% of users will not be affected by these limits. They are designed to impact only teams with exceptionally high API usage.
Rollout plan:
We will monitor actual API usage for 1-2 weeks after release before gradually enforcing the limits, giving everyone time to adapt.
More details about the upcoming release and these changes will follow soon on https://seatable.com, on this forum and via newsletter.
If you have any questions or concerns, please don’t hesitate to reach out here in the forum.
Does this mean that the original Make.com app (the one maintained with Make.com themselves) will stop working after we get the 5.3 update? Or does that app use the new API endpoints already?
The apps for n8n, Zapier, and Make.com (the verified version) all use the API-gateway. If you are using the latest versions, no additional action is required.
Additional Info - these problem also happens in Zapier. Our Zap shows me an Error:
"## Failed to create a row in SeaTable (3.0.14)
404 Not found. Please check if the target URL and HTTP Method is correct."
If i test the connection, it works without any problem (Your account connection is working correctly.).
Regarding Zapier, please upgrade from 3.0.14 to 4.0.6. This will fix your issues immediately.
If you have problems to do that, write me a private message with your email and I will migrate your zapier workflows for you.
make.com. just did a test and I successfully listed rows. I first thought it could be the old Seatable → “rework” → old is now new Seatable. When I swapped out the modules for “verified” (searched in Make for SeaTable, did not merely select the quick links), I saw that there was a list of deprecated modules. I made sure i chose the working ones, and it worked.
Hmm, I am getting a problem with Instagram, that Insta needs to access the publicly accessible link but it is throwing an 0Auth error. Potential explanation is blocked access. Could however be caused by too many tests of the same scenario.
The link starts thus. Is this right? https://cloud.seatable.io/seafhttp/files/ (this is followed by a string and then the file name). The url is decoded
Now I am getting an error with the “verified” SeaTable module for “create a row”. Failed to load data and getaddrinfo ENOTFOUND null.
I am connecting to SeaTable via another account.
Quick question: If I establish a new API connection to SeaTable, will that solve the issue? If so, what is the link to establish a new connection to make.com? The default is https://cloud.seatable.io . Is this still valid?
If anyone is using the seatable_ruby gem - we have just moved all remaining endpoints to the v2 api-gateway (quick fix) - so that the gem should work again. Let us know on github if not.
By hotfix do you mean that make is now working? If so, I can say that it isn’t. I tried to reauthorize the connection to seatable and i got the following response: The request failed due to failure of a previous request. Invalid OAuth provider address.
Please advise. For example, should i set up a new API connection to SeaTable to replace the current one?
The forum and blog post don’t specifically mention self-hosters, but is the change the same for us, meaning that upgrading to 5.3 will break any applications using the old API?
Dear pt42,
One of our main goals is that self-hosted systems behave the same as SeaTable Cloud.
Consequently, I you stick to our default setup, the dtable-db and dtable-server endpoints will be removed with an upgrade to version 5.3.
For experienced admins, it should be possible to keep the old endpoints at least until v6.0. Revent the nginx configuration for /dtable-server and /dtable-db in this file /opt/seatable-compose/config/seatable-nginx.conf.
The connection to make is not working fully anymore. Accessing directly through API works now with the update server, but in the seatable modules it can’t get the /dtable-server/....
