Frequent ETIMEDOUT Errors When Requesting Seatable Metadata API Endpoint

Hi there,

I am sending a HTTP request to metadata every hour, but most of the request end up in a ETIMEDOUT Error. Very few requests actually go through.

Does anyone know how to solve this, or is this just the API endpoint not working properly or being unstable?

{ “headers”: { “accept”: “application/json”, “authorization”: “hidden” }, “method”: “GET”, “uri”: “``https://cloud.seatable.io/api-gateway/api/v2/dtables/123e4567-89ab-4def-0123-456789abcdef/metadata/”``, “gzip”: true, “rejectUnauthorized”: true, “followRedirect”: true, “resolveWithFullResponse”: true, “sendCredentialsOnCrossOriginRedirect”: true, “followAllRedirects”: true, “simple”: false, “timeout”: 300000, “encoding”: null, "j

SeaTable Cloud’s API is stable and working within normal parameters: https://status.seatable.com/

You can test it at Get Metadata.

The ETIMEDOUT error means the TCP connection itself times out before reaching the server. This is not an API issue - it indicates a network-level problem between your client and cloud.seatable.io.

A few things to check:

  • DNS resolution: Make sure cloud.seatable.io resolves consistently from your server. Try nslookup cloud.seatable.io or dig cloud.seatable.io at the time of failure.
  • Network/firewall: If your client runs behind a corporate firewall or proxy, outgoing HTTPS connections may be blocked or throttled intermittently.
  • Connection reuse: With hourly requests, idle connections may be dropped by intermediate proxies. Make sure your HTTP client opens a fresh connection each time rather than reusing a stale one.
  • Test from a different network: Try running the same request from a different machine or network to isolate whether the issue is specific to your environment.

The metadata endpoint itself is stable. You can verify this by running a quick test from your local machine:

curl -s -o /dev/null -w "%{http_code}" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  "https://cloud.seatable.io/api-gateway/api/v2/dtables/{base_uuid}/metadata/"

If this returns 200 consistently, the problem is in your client’s network environment.

Best regards
Christoph

Thanks for this. I have investigated and found the issue to be between the self-hosted n8n and the Node installation. Somewhere, the request that’s being made by the HTTP node is not working properly in this case.

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