At a glance
Days until your ShippyPro API auth token expires. When the token expires, every label-print, rate-shop, and tracking call fails immediately, breaking despatch end-to-end until a human re-authenticates. This is the most operational of the operational-health cards: a silent ticking clock that turns into a P1 incident the moment it hits zero.
Calculation
Calculated automatically from your ShippyPro data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
The Italian DTC fashion brand. Reading taken at 09:00 CET on 12 Mar 26.
The card reads 2 days for the primary workspace; the alert at
<14 days has been firing for 12 days already. Five things to notice:
- The clock has been counting down for 363 days; nobody noticed for 351 of them. This is the failure mode of token-expiry: silent until it isn’t. The 14-day alert is meant to guarantee humans notice with two weeks of cushion. If the alert was acknowledged but the rotation work was deprioritised, escalate now.
- Two days is a P1 weekend risk. If the token expires at 14 Mar 26 03:00 CET (the original issue timestamp), Saturday morning despatch breaks. Operations on Monday will find unprocessable orders backlog from Sunday plus Saturday overflow. The fix window before P1 is the next business day; rotate today.
- The fr workspace is healthy and is the rollback path. If the it rotation goes wrong, the fr token can technically print labels for it shipments via a workspace switch, with manual rate-card and template overrides. Document the rollback path before rotating.
- Re-auth requires a human in ShippyPro’s UI. The OAuth flow needs an admin user to log into ShippyPro Settings → API & Integrations → Generate New Token, copy the new bearer, paste into the Vortex IQ connector settings. Coordinate the rotation with despatch downtime (typically <5 minutes if pre-staged).
- After rotation, the card resets to 365 days (or whatever the issue-time window is). Re-read the card 24 hours after rotation to confirm the new expiry has propagated; if the card still shows <14 days the new token did not save correctly. Record the rotation in the change-history block of the workspace.
Sibling cards merchants should reference together
Token-expiry is binary at the day level (alert fires or not), but it is a leading indicator for a chain of operational cards. Pair with these to anticipate impact:Reconciling against the vendor’s own dashboard
Where to look in ShippyPro’s own dashboard: ShippyPro Settings → API & Integrations. The page lists the active token, issue date, expiry date, and a “Rotate” button. The card and the portal read the same source; numbers should match exactly. If they differ by more than a few minutes, the connector poll cycle is stale and a manual reconnect refreshes the read. Why our number may legitimately differ from ShippyPro’s portal:
Cross-connector reconciliation: