TL;DR: Official docs (Vault API reference): documents POST /vault/connections/{unified_api}/{service_id}/validate, a dedicated endpoint to check a connection's state, plus /token (authorize access token) and /authorize/{service_id}/{application_id} for re-authorization. Connections go stale when users revoke access or tokens expire, and the tripping point is calling unified APIs on a dead connection instead of validating first. ## What to do Before calling any Apideck unified API on a stored connection, hit POST /vault/connections/{unified_api}/{service_id}/validate to check its state.

## Fix
1. Official docs (Vault API reference): documents POST /vault/connections/{unified_api}/{service_id}/validate, a dedicated endpoint to check a connection's state, plus /token (authorize access token) and /authorize/{service_id}/{application_id} for re-authorization.
   Expected: this specific failure stops.
2. Connections go stale when users revoke access or tokens expire, and the tripping point is calling unified APIs on a dead connection instead of validating first. ## What to do Before calling any Apideck unified API on a stored connection, hit POST /vault/connections/{unified_api}/{service_id}/validate to check its state.
   Expected: this specific failure stops.

## Details
If the connection is broken (revoked OAuth, expired credentials), send the user back through Vault to re-authorize: GET /vault/authorize/{service_id}/{application_id} for the OAuth flow, or POST .../token if you have a fresh access token to attach. Build this as a standard pre-flight: validate, and on failure redirect to Vault instead of letting downstream calls 401 one by one. Keep connections per consumer (POST /vault/consumers), since auth state is per end-user, not per your app.

## When to use
You hit exactly this: Apideck: validate connections before calling unified APIs in Apideck.

## When not to use
A different error, or the same symptom in a different tool. This page only covers the failure above.

## Compatibility
Apideck.