Two ways:

1. API limits are usually per user (OAuth token, API token), not per API consumer. 5000 per user is a lot. The exceptions are ancient APIs, actually want to constrain usage, or didn't think about how their API would be consumed.

2. Honor cache headers and, headers or not, know the data well enough to cache thoughtfully.

We consume 40+ APIs for https://tacoapp.com/ and even with a full day as #1 on ProductHunt, the only APIs we had to worry about were those tied to the consuming app instead of to the user (API token) or user+consuming app (OAuth token).

Basically, if you build an API, base limits on the number of users a consuming app is acting on behalf.

Another big way to reduce impact on your rate-limit (at least with Github) is conditional requests.

If-None-Match / If-Modified-Since and using the E-Tag header.

If the resources have not been modified, or doesn't match that revision it won't count towards your limit.

AFAIK it’s a browser extension, so it doesn’t need API calls, it integrates itself into GitHub.

This one does, but the ones like huboard and waffle.io use the API.

GitHub is very lenient with their rate limits if you just ask. I'd guess huboard and waffle.io have agreements in place where users authenticated through them have higher limits.