SeaTable 4.4 out now!

Version 4.4 of SeaTable Server is now available. It can be downloaded from the well-known Docker Hub repository.

And we didn’t waste any time making the release’s numerous feature additions and improvements available to our cloud users: SeaTable Cloud was updated this morning 6 am CET.

The following highlights are available to Free, Plus, and Enterprise subscribers:

  • Improved page types in universal app builder: Build powerful dashboards with more design options on custom pages, handle data on table pages faster thanks to new mouse actions, use collaborator columns in form pages, drag and drop records on calendar pages, and allow user interaction on query pages with buttons

  • Supercharged Excel import: Select the sheets to import from your XLSX-workbook and start working on the data much faster than in the past

  • Common dataset push sync: Force the synchronisation of your common dataset to ensure your partners use the most up-to-date data

  • Sync common datasets with existing tables: Resync tables in bases that you created from a template or that you restored from a snapshot

  • „Sticky“ links to common datasets: Copy bases and retain the link to the common dataset in the new bases

  • Universal default values: New rows are populated with the defined default values no matter how new columns are created – manually or via a form, button, or automation.

As announced, SeaTable 4.4 says „good bye“ to the gallery app builder and replaces the „old“ data query app builder with a new one based on the universal app builder.

You find the Release Notes for SeaTable 4.4 in the SeaTable Blog. For those of you that want more details, you find all changes – as always – in the Changelog.


As always, there is also a video for the new release, this time with subtitles in your preferred language.

1 Like

Great news thanks for improving constantly!

I feel like the new version also introduced some API changes, because we started having issues with dates (has the return format changed?) and also duplication of records (get_row and then append_row) - I will come back when I have more details

I see now the api pages use
and we’re on

Dear @siax84,

thanks for feedback. With 4.4 we introduced the so-called API gateway, which will allow us to implement API limits in the future. I already wrote about this in the past: Updates to Our Subscriptions - Introducing Team API Limits

In addition, the API gateway also harmonizes and improves all dtable-db and dtable-server endpoints. But all former endpoints stay alive and can still be used. Look at our API documentation at, you will find all new and former endpoints.

Long story short:

  • if you observe changes in the output, please return to us. This should not be the case and we will fix this.
  • you don’t have to switch to the new API endpoints. The old endpoints are still valid.
  • some clients require an additional parameter to follow the redirect. In case of curl, you have to add -L to the command.
1 Like

Thanks a lot for your help and explanations!
The differences I noticed are

  • dates coming via List Rows (v1 endpoint) are now formatted string with the setting as configured in the table (in our case “German” format and previously were always coming as ISO date strings
  • Get Row with row_id returns nothing now for existing IDs in an untouched implementation. The website works however as expected using v1 endpoint.

EDIT: I see that v1 endpoint for Get Row is doing a 302 redirect to the v2 endpoint and our implementation wasn’t following the redirect. So as both endpoints seem to be equivalent switching to v2 endpoint or dealing with the redirect solves the issue.

I apologize, if the date format changed, that was not our intention. I will clarify that.
Regarding your second point, I already answered this in my last answer:

I assume that your implementation of the API does not follow redirects and therefore delivery zero output.

1 Like

Let me give you a short update.

It was not our intention to generate breaking changes in the API. Therefore, just one hour ago, I deactivated the redirect of the calls Get Row and List rows to the new API-Gateway. As a consequence, the API should now behave like it did in the past.

We will re-activate in the future these redirect after we made sure that the output of the API does not create breaking changes. The necessity that the clients support redirects will be activated most likely in the future again.

I am sorry for these changes. Please check your scripts and integrations that they work as they should. I keep you updated.


Unwanted changes happen and it’s outstanding that you acknowledge and address them so quickly. For our part the issue was identified and fixed in a day by following the redirect and dealing with the date format. The seatable_ruby gem has now a new branch to support the v2 endpoints. It will be merged into main when we have tested a bit more.

1 Like

The resync of common datasets is very handy!