Seatable for hosting content vs. Quota limits


we successfully used SeaTable for our last two projects. While some aspects worked extremely well, we had mixed experiences on other areas (esp. unannounced breaking API changes and extremely low API quotas).

Overall we would love to work more with SeaTable and also use it for hosting media content like images and video files. Sadly the current cloud quota limits absolutely disqualify SeaTable for this kind for projects.

Ideally we would need a “charge by traffic” system similar to google API service, because the worst case scenario is broken apps because of the 60 requests per hour quota.

I asked a similar question here. Any plans that hosting media assets on the SeaTable cloud will be available in the future?

with kind regards,

Hi Tom,

thanks for your post, I think this should be a nice feature request for us. Currently I don’t see plans for “charge by traffic”.

One thing that concerns me is: I think we have 600 request per hour instead of 60. Are you sure you are facing 60 as a limit?

Other limits can be found in this article.

kind regards,

Hi Karlheinz,

Thanks for your quick answer. Ideally there should be some kind of pricing model to avoid quotas at all. In our case implementing caching is not feasible, because we didn’t find a solution to fetch multiple media download links with single call.

Our clients want to update texts and media content on the fly (around 50-150 images). Getting the updated list or assets is a single call, but showing / downloading these 150 images is not possible, because the first response does not include download URLs; you first have to resolve each URL individually.

I’m not sure about the most recent quota but during our project (roughly two months ago), it was changed from 600 to 60 (Which I personally think is unreasonable low).

Also see your earlier response here: API Quota limit (60 calls per hour) exceed

kind regards,

So you are writing this post based on an experience two months ago.

I just checked the system: the limit of API calls is 600 calls per hour and 100 calls per minutes for the List Rows request.

This limit doesn’t apply to other requests. If you can name the exact request you have a quota problem with, maybe I could help you.

Hey tom,
Christoph here from SeaTable. Please let me jump into this discussion and answer your request about a new pricing model:

  • There are no plans to add such a price plan to our saas offering because we don’t want to over complicate things.
  • BUT: with regards to your requests I want to propose that a self hosted installation or even better a dedicated cloud would be much more appropriate.

In both cases you are in full control over the system and you can rise the limits to any number you want. You want unlimited api calls? No problem, we just disable this limit.

If you decide for a dedicated cloud we will build your private SeaTable System on the same environment like we use for And we will take for of everything: Updates, Maintenance, Security Patches of the linux system… On top you decide which url you want to use for the system and what templates or logo you want to use. It is your own system.

If this sound interesting, please let me know then I will provide you with more info. By end of next week this infos will also be available on our website.

Best regards

Hi Karlheinz,
Hi Christoph,

I had to get some feedback from my team first. I looks like for us the quotas are currently still applied and mostly caused by having to fetch the download URLs individually as I described above. We’re currently evaluating multiple possibilities to move forward. Self-hosting is one of those (which we had already running but weren’t able to apply because of some restrictions within the client’s IT infrastructure).

Dedicated cloud hosting sounds like another solution I haven’t thought about. Thanks for pointing that out. As soon, as I know more details, I will contact you.

Thanks again for your help!

kind regards,

Hi Karlheinz,
Hi Christoph,

I am part of Toms (@pixtur) team.

We are using seatable as the database for several applications, allowing content editors to modify texts, images and videos. The application then imports and caches the db contents and their attached media files.

We were and are still running into the 429 Too Many Requests Problem. To download the files we first have to generate download urls via the ${baseUrl}/api/v2.1/dtable/app-download-link/?path=${filePath} endpoint. This endpoint is limited to 60 requests per second.

As it is not really documented whether the generated links expire at some point, there is no batch url to generate all download urls at once and there is no file-hash included to let us check for changed files, we have to generate each download link individually on each update.

So as soon as we have more than 60 files each client will have to wait for a minute. As we had hundreds of content entries each with 1-5 files attached, this lead to inordinate waiting times when updating content.
Luckily we only had a few clients, but with the hourly limit this will get even worse once there are more than 3 users updating within the same hour.

It would be good to know:

  • can seatable support an asset database use-case as described above?
  • is there some way to solve the quota limits on the app-download-link endpoint?


The error “429 Too Many Requests” comes from the limitation for RestAPI calls for logged-in users. A simple solution is to add a feature that a user can generate a permanent asset access token for a base, then use a path like to access a file.

But on the other hand, is paid by number of users not by the resource usage. Such kind of usage can easily take a lot of network traffic and cause a loss.

The better solution is to use a dedicated hosted server with fixed bandwidth or monthly maximum of network traffic.

Hey Hendrik, hey Tom,

the topic is complex but let me try to explain the details. Currently has some limitations. You can find them at System Limitations - SeaTable Admin Manual. Some of these limitations are fixed, some can be configured.

We chose these limits with two goals in mind:

  • we want to make sure that all our customers get a fast and reliable system.
  • we want to prevent a usage that creates more costs that we charge our customers.

Now your problem has two dimensions:

  1. raising the limits
    The limitations that are relevant in your case are the api calling rates. “API calling for single base” is limited to “300/min”. These values could be configured globally via config file. Therefore a solution for you would be to choose a “dedicated” or “self hosted” system. “Dedicated” means that we build and maintain your own instance of SeaTable. “Self hosted” means that you maintain it by yourself. In both cases you could rise the limits to any value you want. Right now there are only a few infos about these two products on but we will update our website next week and add more info about these two products.

  2. general usage of the api-calls
    the second dimension is that it is not smart to generate a download link for every file / picture that you have in a base, every time you access the data. We had this problem also on our wordpress website. If you access the templates-page you get a list of all templates that is completely generated from a SeaTable base. Of cause we could use an api call to get all rows and then additional api-calls to get all the download-links for all the pictures. But this takes a lot of time and ressources.

In our case we wrote some code that detects if the files have changed and then download and cache the files to the wordpress system and use the files locally. Our wordpress detects if the files have changed with the help of the _ctime-column and only loads the images again if the _ctime had changed. This works quite well and reduces the load time of the page.
Because this might not work for everybody I agreed with the developers that there will be a new api call to get access to files and pictures of a base with a kind of asset_access_token. It will soon be available. Still the api limits on might not high enough for your case.

*) long story short:
rethink your code about accessing files and pictures. There might be possibilities to cache the files/pictures either on the server or the clients. Still will always have limitations regarding heavy API usage. If you need higher limits, you should definitely go with a dedicated or a cloud system.

Best regards

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.