Cap your Fivetran API client at 100 requests per minute and implement exponential backoff with jitter on 429 RateLimitExceeded. Cache GET responses (a 5-minute TTL is a reasonable default) instead of re-listing on every run. Parse error responses defensively: check the content type before calling .json(), because 5xx responses can come back as HTML. Serialize bulk list calls rather than firing them in parallel.

Context: GitHub integration notes (rocky Fivetran skill, real implementation notes): documents the Fivetran REST API rate limit as 100 requests per minute and advises implementing exponential backoff on HTTP 429, plus caching GET responses. The same notes warn the API can return HTML on 5xx errors, so clients must handle non-JSON responses gracefully instead of crashing in the JSON parser. Agents that fan out list calls in parallel or assume every error body is JSON hit throttling and parse crashes that look like API bugs.