How we avoid hitting our flight-data provider's rate limit

Fetching real prices for 13 origins across 40 destinations, every hour, adds up fast. Before turning the hourly pipeline on for real, we confirmed the actual numbers rather than assuming they'd be fine.

The real limit, confirmed directly

Our flight-data provider's own support team confirmed their price-lookup endpoint is limited to 300 requests per minute, per API token — a hard, documented number, not an estimate.

What our actual usage looks like

13 origins times 40 destinations is 520 requests per hour at full scale — comfortably inside the 300-per-minute limit even before spreading anything out, since 520 requests in an hour averages under 9 per minute. The provider's own guidance is still to spread requests evenly across the hour rather than bursting all of them at once, which is what the fetch script actually does, rather than firing 520 requests back-to-back the moment the hourly job starts.

Why this matters for you as a reader, not just us

A rate-limit violation wouldn't just be an internal annoyance — it would mean silently missing data for some destinations that hour, the same kind of gap that would eventually surface as an honest "no data" or "Building history" state on the board. Confirming real headroom before scaling up origin coverage is part of the same discipline behind not guessing at numbers we haven't verified.

See today's board