Build a status badge from a cacheable read

Poll a cheap read

Call the loyalty endpoint from your server every minute or two — far under the 60/60 s limit — and cache the outcome for all page views to share.

Define the badge states

Green on a 200 with a recent generated timestamp; amber on a 429 (that is your probe, not the API — slow down); red on a 5xx or timeout.

Never probe writes

Drive the badge from a read only. Posting enquiries to check health pollutes real data and burns rate budget. See monitoring.

Why a read makes a good probe

A status badge is only trustworthy if the check behind it is cheap, honest and side-effect free. A cacheable read like the loyalty tiers fits perfectly: it changes nothing, carries no personal data, and returns a timestamp you can use to confirm freshness. Polling it slowly from your server — every minute or two — keeps you far below the rate limit while still catching a genuine outage quickly. The one trap to avoid is treating a 429 as a fault: that response means your own probe is calling too often, not that the platform is unwell, so the right reaction is to slow down rather than raise an alarm. Never drive a badge from a write endpoint, which would pollute real data.