Why does a historical fetch return a 504 timeout?

Large synchronous historical pulls (to_webhook=false) can exceed the response-size limit or the ~30s gateway timeout, returning 504 / 413 / 500, especially…

Large synchronous historical pulls (to_webhook=false) can exceed the response-size limit or the ~30s gateway timeout, returning 504 / 413 / 500, especially with many activities or with_samples=true (heavy GPS/HR series).

What to do:

• Chunk the request into smaller date ranges (e.g. several 3-10 day or month-by-month requests) for faster parallel responses, or reduce the range.

• Use with_samples=false for summaries.

• Best of all, use to_webhook=true to return immediately and deliver data asynchronously to your webhook without the size limit.

Within a request, data is returned in chronological order. For latency-sensitive flows, fetch-on-connect and cache, then rely on webhooks. Elevated latency on read endpoints is usually transient infra load, so retry after a short period.

504s shown in payload history (versus on your request) mean your server is not acknowledging fast enough, so process payloads asynchronously and return a quick 200.

end_date is exclusive, and you cannot request only specific sample types (all or none).