At a glance
Days remaining until the Bring API authentication token expires. When the token expires, every Bring booking, label-generation, tracking-event ingestion, and claims-submission API call from Vortex IQ to Bring fails with HTTP 401. The Vortex IQ to Bring integration goes silent; bookings have to fall back to manual Mybring entry; the Nerve Centre dials read stale data. This card is the operational equivalent of the engine-warning light: green for two months at a time, then a hard red with 14 days notice.
| What it counts | expiry_at - now() in days, where expiry_at is the expires_at field on the active Bring API credential stored in the integration secret manager. Negative values are clamped to 0 (“expired”). |
| API endpoint | The card does not call Bring directly; it reads the stored credential metadata. Bring’s API uses a long-lived API key (Mybring API key + customer-number pair) by default; OAuth-style integrations (used by some enterprise customers) generate refresh-token pairs with a typical 90-day refresh-token lifetime. |
| Token type | Mybring API key + customer-number pair: typically 12-month rotation, customer-managed. OAuth refresh-token: typically 90-day rotation, auto-refresh-eligible. The card surfaces whichever credential type is active; the rotation cadence determines the alert frequency. |
| Auto-refresh | OAuth refresh-tokens auto-refresh inside the 14-day warning window if the refresh API responds successfully. Static API-key pairs require a human action: log into Mybring, generate a new key, paste into Vortex IQ integration settings. The card alerts in time for the human action. |
| Service-tier scope | The token covers all Bring API surfaces: Booking, Tracking, Invoicing, Claims, Reports. There is one token per integration; expiry hits everything at once. |
| Returns / RTO | Not relevant. The card is about the integration credential, not shipment data. |
| Currency | Not relevant. |
| Time window | RT (real-time count of days, refreshed at integration sync). The dial reads the credential’s stored expires_at and computes the delta against current UTC. |
| Alert trigger | <14 days. Triggers when the active credential is within 14 days of expiry. The 14-day window is calibrated to allow time for the merchant to schedule a token rotation, log into Mybring, generate a replacement, paste it into Vortex IQ, and verify the new credential before the old one expires. |
| Roles | owner, operations |
Calculation
Calculated automatically from your Bring 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 Drammen-based outdoor-apparel merchant, integrated with Bring via a Mybring API key + customer-number pair (the standard Norwegian SME setup). The credential was generated on 12 Mar 25 with a 12-month rotation and is set to expire on 12 Mar 26. Reading taken at 09:00 CET on 27 Feb 26.| Day | Card reading | Status | What happens |
|---|---|---|---|
| 12 Mar 25 | 365 | green | Credential just generated, full lifetime ahead |
| 12 Sep 25 | 182 | green | Halfway through lifetime, dial is informational only |
| 11 Feb 26 | 29 | green | One month to go, dial still green |
| 26 Feb 26 | 14 | warn | Alert fires, dashboard turns amber, integration owner emailed |
| 04 Mar 26 | 8 | warn | Reminder email; calendar nudge to schedule rotation |
| 11 Mar 26 | 1 | critical | Dashboard turns red; rotation must happen today |
| 12 Mar 26 | 0 | expired | Token dead; bookings fail; bookings fall back to manual Mybring |
- The 14-day warning is calibrated to typical merchant scheduling. Most operations teams schedule maintenance work in 2-week sprints; the alert ensures a token rotation can be added to the next sprint without scrambling. Smaller merchants without a dedicated ops team often wait until the alert hits 7 days; that is fine, but the closer to 0 the higher the risk of a missed Friday afternoon.
- The rotation playbook is short and well-documented. (a) Log into Mybring, (b) navigate to Settings → API → Generate New Key, (c) copy the new key + customer-number, (d) paste into Vortex IQ → Integrations → Bring → Update Credentials, (e) click “Test connection” and verify the green tick. Total time: 4 to 6 minutes for a familiar user. The old key remains valid until midnight UTC on the expiry date, giving overlap.
- Expiry without rotation cascades to every Bring dial. On-Time Delivery Rate, Late Shipments, Exception Rate, Avg Shipping Cost, Open Claims, every Bring card freezes at the last successful sync. The merchant’s operations team is flying blind on Bring data until the credential is rotated.
- Bookings fail-loudly, tracking fails-silently. A failed booking surfaces immediately because the order management system gets a 401 and cannot generate a label. Failed tracking is silent: existing consignments continue to deliver, just without status updates flowing into Vortex IQ. Merchants often notice expiry first as a “where are my new tracking events” puzzle, not as a booking failure.
- Pair this with the API Error Rate card to detect early credential issues. A spike in API Error Rate before the expiry date suggests the credential has been revoked or de-permissioned manually rather than expiring naturally; investigate immediately.
Sibling cards merchants should reference together
Token expiry is an integration-health dial, not a shipment dial. Pair with these to read the integration as a whole:| Card | Why pair it with Days to Token Expiry | What the combination tells you |
|---|---|---|
| API Error Rate | Pre-expiry credential issues. | A rising error rate while expiry days are still healthy suggests permission scope changed or rate-limit exceeded, not natural expiry. |
| Label Generation Success | The first dial to drop on token expiry. | Label generation requires the booking API, which is the first surface to fail with 401; an unexplained drop in label success when expiry is close is a clear signal. |
| On-Time Delivery Rate | Stale-data signal. | If OTD reads have not refreshed for several hours and expiry is at 0, the dial is showing pre-expiry data; the carrier is fine, the integration is broken. |
| Late Shipments | Stale-data signal companion. | Same logic; counts may freeze rather than continue updating after expiry. |
| Cross-connector: integration-health for adjacent connectors | The merchant’s overall integration credential calendar. | A merchant with Bring, PostNord, Klaviyo, and Shopify all integrated has 4 credential calendars; consolidating them into one operations dashboard prevents the “I forgot about the Bring one” failure mode. |
Cross-connector: vortex_iq.integration_health_summary | Aggregated integration health view. | The Vortex IQ admin layer rolls up every connector’s expiry into a single view; this card is the per-Bring detail behind that summary. |
Reconciling against the vendor’s own dashboard
Where to look in Bring’s own portal: Mybring → Settings → API, the “API Keys” panel lists all active and expired credentials with theirCreated at, Expires at, and Last used timestamps. The card’s reading should match the active credential’s Expires at field exactly. If the dates differ by more than 1 day, the integration credential record is out of sync with Mybring; force a refresh in Vortex IQ → Integrations → Bring → Refresh Credentials.
Why our number may legitimately differ from Mybring:
| Reason | Direction | Why |
|---|---|---|
| Timezone (CET / CEST vs UTC) | Off by 1 day at boundary | Mybring shows expiry in Oslo local time; the card uses UTC. A credential that expires at 23:30 CET on 12 Mar reads as 12 Mar in Mybring and might read as 13 Mar in the card. The card resolves this by always rounding down to “days remaining”; the alert fires correctly regardless. |
| Multiple active credentials | Either | A merchant may have multiple Mybring API keys for the same customer-number (one for production, one for sandbox); the card reads the credential active in the Vortex IQ integration. If the merchant rotates a different credential than the one Vortex IQ uses, the dial does not move. |
| Manually revoked credentials | Ours higher | If a credential is revoked manually in Mybring before the natural expiry, the card may continue to read the original expiry-days value until the next sync. The first 401 from Bring forces a re-read and the card switches to “expired”. |
| OAuth refresh-token vs API-key | Either | OAuth integrations refresh automatically inside the alert window; API-key integrations do not. The dial behaves differently between the two types; the card’s reading is the credential lifetime, not the user’s effective access. |
| Card | Expected relationship | Causes of legitimate divergence |
|---|---|---|
| Adjacent connector token expiry cards | Different connectors, different credential calendars. | No expected relationship; cards are independent. |
vortex_iq.integration_health_summary | The summary view should always include this card’s value. | If the summary shows green and this card shows warn, the summary refresh is stale; force-refresh. |
Known limitations / merchant FAQs
My token rotates every 12 months. Why does the alert fire 14 days early? The 14-day window is the safe buffer for human-led rotation. If you forget about the alert until the day before, you have less than 24 hours to log in, generate, paste, test, and verify; that is too tight for a Friday afternoon discovery. The 14-day window gives time to schedule, delegate, and recover from a failed test. If your operations cadence supports tighter scheduling, the alert threshold can be set to 7 days at the integration level; below 7 days is operationally risky. The card reads “expired” but my Bring integration still seems to work. Why? Three possibilities. (1) Sync lag. The card reads the cached expiry value; if the card has not refreshed since the credential was rotated in Vortex IQ, the dial may still show the old expiry. Force a refresh. (2) Multiple active credentials. Bring sometimes allows old + new credentials to overlap for 24 to 48 hours after rotation; the integration may still be using the old (now technically expired) credential while the new one warms up. (3) The card is reading the wrong credential record. If a previous integration was disconnected and a new one connected, and the old record was not cleaned up, the card may be reading the dead record. Reconnect the integration to be safe. Can I rotate the credential before the alert fires? Yes, and it is the preferred operations pattern. Set a 90-day calendar reminder (“rotate Bring API key”) regardless of when the natural expiry is; rotate proactively. The Mybring portal generates a new credential pair without invalidating the old one immediately, so there is no downtime risk. Pattern: generate new, paste into Vortex IQ, test, then revoke the old one in Mybring once the new one is verified. My API key was generated by a colleague who has left the company. Should I rotate it? Yes, immediately. Generation is bound to a Mybring user; if that user’s Mybring account is deactivated, the generated keys may stop working without notice. Best practice: generate keys against a Mybring service-account user (a non-personal account owned by the operations function), rotate when the binding user changes role, and never bind credentials to a personal Mybring account. What happens to my Open Claims data if the token expires? The card reads stop refreshing; the data already in Vortex IQ remains visible but stale. New claims filed in Mybring are not picked up; status changes on existing claims are not reflected. This is a real risk for finance because the dial may continue to read “32 open claims” while the actual count has moved. Treat token-expiry as a finance-data-integrity event, not just an operations event. OAuth-style integration: does the alert fire on access-token or refresh-token expiry? Refresh-token. Access tokens for OAuth integrations expire every 1 to 24 hours and refresh automatically; the card does not surface them. Refresh-tokens have a 90-day rotation window and require the OAuth flow to complete (usually a browser redirect) when they expire; the card surfaces this expiry and alerts at 14 days remaining. For OAuth merchants the alert is structural; expect it 4 to 5 times a year. The Mybring portal shows my credential as “active” but the card says expired. Who is right? The card. The alert reads theexpires_at field on the credential record; if Bring has not yet revoked the credential at midnight UTC on the expiry date, Mybring may continue to show “active” until the next housekeeping cycle, but every API call after midnight UTC will fail with 401. Trust the card; rotate immediately.
Can I get a webhook notification instead of an in-dashboard alert?
Yes. The integration-health alert framework supports webhook delivery to Slack, Teams, email, and custom webhooks. Configure once at the integration level; the same trigger that lights up this card also fires the webhook. Most operations teams configure Slack alerts on this card to a dedicated #integration-health channel.
The card just turned green again from “expired”. What happened?
Someone rotated the credential. Check the integration audit log for who and when; the card flips to green within 1 sync cycle (typically 5 to 15 minutes) of the new credential being saved. If you did not authorise the rotation, treat as a security event and audit the rotation operation.