An upstream API can be healthy and still decline a request because a client has reached its quota. Treating rate limits as an exceptional surprise makes an integration fragile. Designing for them from the start makes the application easier to operate.

Cache where the data permits it

Public repository metadata, advisory catalogs, and reference information often do not need a fresh request for every page view. Use a documented cache lifetime and make it visible when a panel is showing older data. Keep user-specific or sensitive responses out of shared caches.

Respect the server’s response

Read status codes and rate-limit headers. If a provider supplies a reset time or a Retry-After value, use it to explain when another attempt is reasonable. Avoid an immediate retry loop: it consumes quota while making recovery less likely.

Keep credentials on the server

Store private tokens in server-only environment variables. Do not place them in public build variables or client bundles. Use the narrowest token permissions that support the integration and rotate credentials using the provider’s documented process.

Make failure understandable

Show a concise message when live information is unavailable, retain a clearly labeled cached or curated state where safe, and offer a retry action only when retrying could help. Log diagnostic details on the server without returning stack traces or credentials to visitors.

References

• GitHub REST API documentation
• GitHub REST API rate limits