On July 15th 2024, SeaTable version 5.0 will introduce significant changes to the API. This summary outlines the upcoming changes, with some relevant to the general API and others specific to SeaTable Cloud.
If this text is too long for you, you will find a short summary after each paragraph:
Example for the summary of this paragraph
1. API Gateway is Recommended, Not Mandatory
The new API gateway endpoints are recommended for all future applications. You can find them at SeaTable API Reference - Base Operations or just by looking for the URL containing /api-gateway/.
However, it is not required to update or change existing apps. The old endpoints are not deprecated and remain valid. Existing automations and integrations using platforms like n8n, Make.com, or Zapier will continue to work without updates.
2. SeaTable Cloud Redirects Some Calls to the API Gateway
Approximately 70% of all requests to SeaTable Cloud are external API requests, mainly for Get Row, List Rows, and List Rows with SQL.
The new API gateway offers faster responses by checking if the base has remained unchanged since the last request. Consequently, we decided to redirect these three endpoints to the API gateway to reduce the overall load of SeaTable Cloud.
The requests are not proxied, but instead return a 302 header redirect with the new URL. Most integrations and software tools, such as n8n, Zapier, Make.com, and libraries like requests (Python), Guzzle (PHP), and Axios (Node), will follow these redirects automatically.
However, with cURL, you need to use the -L parameter to follow redirects. Otherwise, no output will be received.
Example for adding the -L parameter to a curl request:
curl --request GET -L \
--url 'https://cloud.seatable.io/dtable-server/api/v1/dtables/...' \
--header 'accept: application/json' \
--header 'authorization: Bearer ...
(most do this automatically!)
3. Harmonization of Data Outputs
The output format for the Get Row and List Rows endpoints will change with the redirect to the API gateway. To avoid breaking changes, SeaTable ensures that the output format remains consistent even with these redirects.
However, there are two exceptions:
- Link columns now return an array containing
display_valueandrow_idinstead of a string with only thedisplay_value. - Link-Formula columns now return the appropriate output type depending on the result. Single numbers are returned as integers, while multiple values are returned as arrays.
# output before 5.0 of a link column
{
"link": ["value 1", "value2"]
}
# output with 5.0 of a link column
{
"link": [
{
"display_value": "value1",
"row_id": "A1R_7bMzQxexjVHa0_vgZw"
},
{
"display_value": "value2",
"row_id": "MwznxkdhS7y15HdlAE1uDg"
}
}
# output before 5.0 of a link-formula column
"link-formula-countlinks": "6"
"link-formula-lookup": "value 1, value 2",
# output with 5.0 of a link-formula column
"link-formula-countlinks": 6,
"link-formula-lookup": [
"value 1",
"value 2"
]
These adjustments harmonize the output of Get Row and List Rows to be consistent with the List Rows with SQL endpoint!
Self-hosted and dedicated SeaTable server systems are not affected by this, as there the three endpoints are not redirected to the API gateway and the output remains the same.
This is only relevant for these two endpoints: Get Row and List Rows.
If you are using the List Rows with SQL endpoint already, you are not affected by this change.
4. Retrieve Current Rate Limits
API Gateway endpoints return the current rate limit usage through x-ratelimit headers. These headers provide the daily limit, current usage, and the next reset time as a Unix timestamp in seconds. Below is an example of the returned headers:
x-ratelimit-limit: 5000
x-ratelimit-remaining: 4996
x-ratelimit-reset: 1720710405
More information about the new release will be available soon.
I wouldn’t think python pipeline can be involved in our scenario
