At a glance
Countdown, in days, until the EasyPost credential your despatch operation relies on to buy labels and pull tracking stops working. EasyPost itself issues a long-lived API key rather than a short OAuth token, so this card is the early-warning clock for any credential on the account that does expire: an API key with a self-imposed rotation cut-off, an underlying carrier account’s auth grant (for example a directly-linked UPS, FedEx or DHL account), or a webhook signing secret on a deprecation schedule. When the soonest one reaches zero, label purchase and tracking ingestion stop, and despatch halts on the affected lanes.
Calculation
Calculated automatically from your EasyPost credential metadata. The card takes the expiry date of every credential attached to the connected account, subtracts today’s date (in UTC), and reports the minimum across all of them:days_to_expiry = MIN( credential.expires_at - now() ) across {api_key, carrier_account_grants[], webhook_secret}, expressed in whole days, floored.
A few mechanics worth knowing:
- EasyPost’s primary API key does not auto-expire. EasyPost issues a test key and a production key that stay valid until you delete or roll them. So in a default single-key setup this card reads a high, effectively static figure (often shown as “no expiry set” or a far horizon) until you schedule a rotation. The card becomes meaningful the moment you set a rotation cut-off, link a carrier account whose grant does expire, or attach a webhook secret with a deprecation date.
- Linked carrier accounts can expire even when the EasyPost key does not. When you connect a UPS, FedEx or DHL account through EasyPost, the underlying carrier authorisation can lapse (password change, account suspension, OAuth grant revoked). EasyPost surfaces this on the carrier account’s status; the card folds the nearest such lapse into the countdown.
- The minimum, not the average. If your API key has 200 days left but a linked FedEx grant expires in 9 days, the card reads 9. The soonest break is the only one that matters operationally.
- UTC, whole days. The subtraction is done in UTC and floored, so the figure can be one day adrift from a wall-clock reading taken late in the day in another timezone. See the reconcile section.
Worked example
A UK home-fragrance brand despatches roughly 1,800 parcels a week through EasyPost: rate-shopping across Royal Mail, Evri and DPD on the domestic leg, and using a directly-linked FedEx account for its US and EU orders. Security policy requires the production API key to be rotated every 90 days, and the FedEx grant was last re-authorised on 14 Mar 26. Reading taken at 08:30 BST on 23 Jun 26.
The card reads 9 days and is amber: the alert at
<14 days has tripped. Five things to notice:
- The API key is not the problem here, the FedEx grant is. The key has 18 days; the team’s instinct is to look at the key first. But the card is correctly pointing at the FedEx carrier account, whose grant lapses on 02 Jul 26. When that happens, the merchant can still buy Royal Mail, Evri and DPD labels (those are EasyPost-managed accounts), but every US and EU order silently fails rate-shopping and label purchase. The minimum-across-credentials logic is doing exactly its job.
- Nine days is enough time to act without drama. Re-authorising a FedEx account through EasyPost is a few-minutes task in the dashboard, but it needs the FedEx account admin, who may be on leave. Nine days’ notice means the change is scheduled, not fire-fought. This is the whole point of a 14-day amber threshold rather than a 1-day red one.
- Pair this with the connector’s error signals immediately. If the grant has already started failing intermittently, API Error Rate and Tracking API Unavailable / 5xx will be ticking up in parallel. A rising error rate on a credential that is also 9 days from expiry is a strong signal the carrier has already begun rejecting it.
- Label purchase fails first, not tracking. When the FedEx grant lapses, new label buys for FedEx lanes fail at the point of despatch, watch Label Generation Success for the drop. Tracking ingestion for parcels already in flight continues, because those use tracker objects already created.
- The webhook secret at 99 days is noise today, but log it. It is well outside the window now. Note the 30 Sep 26 date so the next rotation is planned and does not become a surprise amber in late September during the run-up to peak.
Sibling cards merchants should reference together
Token expiry is the credential clock. Pair it with the rest of the Operational Health set to see whether a credential is merely approaching expiry or has already started failing:Reconciling against the source
Where to look in EasyPost’s own tooling: EasyPost is a multi-carrier aggregator, so reconciliation happens in two places: the EasyPost dashboard and the underlying carrier’s own account.- API keys: EasyPost Dashboard → Account Settings → API Keys. EasyPost lists each test and production key. Standard EasyPost keys do not show an expiry date because they do not expire; the “expiry” this card reports for the key comes from your own rotation policy stored in the connector, not from EasyPost.
- Carrier accounts: EasyPost Dashboard → Carriers. Each linked carrier account shows its status; a lapsed grant shows as needing re-authorisation. Programmatically this is
GET /v2/carrier_accounts, reading the account status andcredentialsblock. - The underlying carrier portal: for a linked FedEx, UPS or DHL account, the authoritative expiry lives in that carrier’s own developer or account portal (FedEx Developer Portal, UPS Developer Kit, and so on). EasyPost reflects the carrier’s state, but the carrier is the source of truth for when a grant lapses.
Tracking-event ingestion latency does not affect this card directly (it reads credential metadata, not scans), but the same connector poll cadence that ingests tracking events also refreshes the credential clock, so a connector that is behind on tracking will be slightly behind on this countdown too.