The release of SeaTable 6.2 is just around the corner.
This release includes changes to SeaTable’s Python client that may require updates to your existing Python scripts. If your scripts use the Python client, please review them before upgrading to ensure they continue to work as expected.
This post explains why these changes were made, what exactly is changing, and what you need to do.
Who is affected?
This post is relevant if you use the SeaTable Python client in your Python scripts that you run manually or as part of an automation rule.
If you do not use Python scripts or you use Python scripts, but not SeaTable’s Python client, no action is required.
Background
SeaTable’s Python client makes it easy to write concise scripts that interact with your bases. However, one long-standing inconsistency has caused confusion: the format of returned data depended on
- the method or object being used, and
- whether the script was executed manually or through an automation.
Starting with SeaTable 6.2, these inconsistencies are removed. The Python client will return data in a consistent format regardless of where, how, or when a script is executed.
While this change improves the API and makes script behavior more predictable going forward, it is not fully backward compatible. Existing scripts that rely on the previous return formats may need to be updated.
If you host your own SeaTable Server instance, we strongly recommend reviewing your Python scripts before upgrading your SeaTable Server instance.
For SeaTable Cloud and SeaTable Dedicated customers, we will proactively contact the administrators of all teams that currently use Python scripts.
What has changed?
The changes affect the return formats of:
- the current_row attribute of the context object, and
- the query method.
The tables below compare the current return formats with the new formats introduced in SeaTable 6.2.
Context object: current_row
| Column type | Column format | Return format v6.1 | Return format v6.2 |
|---|---|---|---|
| Date | International |
String: YYYY-MM-DD (e. g. '2026-12-24' //'2026-12-24 00:00')
|
String: ISO date-time incl. TZ (e.g. '2026-12-24T00:00:00+01:00')
|
| American | |||
| European | |||
| Germany, Russia | |||
| Formula | Date - International |
String: YYYY-MM-DD (e.g. '2026-12-24' //'2026-12-24 00:00')
|
|
| Date - American |
String: MM/DD/YYYY (e.g. '12/24/2026' // '12/24/2026 00:00')
|
||
| Date - European |
String: DD/MM/YYYY (e.g. '24/12/2026' // '24/12/2026 00:00')
|
||
| Date - Germany, Russia |
String: DD.MM.YYYY (e.g. '24.12.2026' // '24.12.2026 00:00')
|
||
| Number - Number | Custom string |
Float (e.g. 1234.00)
|
|
| Number - Currency | |||
| Number - Percent |
Float (e.g. 0.1234)
|
||
| Link formula | Date - International |
String: YYYY-MM-DD (e.g. '2026-12-24' //'2026-12-24 00:00')
|
List: ISO date-time TZ strings (e.g. ['2026-12-24T00:00:00+01:00'])
|
| Date - American |
String: MM/DD/YYYY (e.g. '12/24/2026' // '12/24/2026 00:00')
|
||
| Date - European |
String: DD/MM/YYYY (e.g. '24/12/2026' // '24/12/2026 00:00')
|
||
| Date - Germany, Russia |
String: DD.MM.YYYY (e.g. '24.12.2026' // '24.12.2026 00:00')
|
||
| Number - Number | Custom string |
List: Floats (e.g. [1234.00])
|
|
| Number - Currency | |||
| Number - Percent |
List: Floats (e.g. [0.1234])
|
Query method
| Column type | Column format | Return format v6.1 | Return format v6.2 |
|---|---|---|---|
| Date | International |
String: YYYY-MM-DD (e.g. '2026-12-24')
|
String: ISO date-time incl. TZ (e.g. '2026-12-24T00:00:00+01:00')
|
| American |
String: YYYY-MM-DD HH:MM:SS (e.g. '2026-12-24 00:00:00')
|
||
| European | |||
| Germany, Russia |
Conclusion
We realize that these changes may require you to update existing scripts, and we apologize for the inconvenience.
We believe the long-term benefits outweigh this one-time effort. By harmonizing the Python client’s return formats, writing and maintaining scripts becomes simpler and more predictable. It also improves compatibility with AI-assisted code generation, as scripts no longer need to account for different return formats.
Finally, Python scripts become truly portable: the same script behaves consistently regardless of whether it is run manually or triggered by an automation.
