Token Vault
Webhook Integration

Error Codes

HTTP status codes, error responses, and retry policy for webhook requests.

Error Responses

Your webhook should return appropriate HTTP status codes. Token Vault maps these to user-facing errors:

HTTP StatusError CodeMeaning
400invalid_requestMalformed request body or missing required fields (no retry)
401auth_failedHMAC signature invalid (no retry)
403setup_requiredWebhook not initialized; run /v1/exchange first (no retry)
410code_expiredExchange code expired (5-minute TTL exceeded, no retry)
410code_usedExchange code already consumed by a previous /v1/exchange call (no retry)
429rate_limitedWebhook is rate limiting; include a Retry-After header in seconds (no retry — Token Vault honors the backoff and propagates it to the calling agent)
500internal_errorUnexpected server error (encryption failure, storage I/O, etc.)
502provider_errorOAuth provider returned an error during refresh
502upstream_errorUpstream service returned an error during /v1/proxy forwarding
504provider_timeoutOAuth provider timed out during refresh
504upstream_timeoutUpstream service timed out during /v1/proxy forwarding

All error responses should include a JSON body:

Error response format
{
  "error": "auth_failed",
  "message": "HMAC signature invalid"
}

Retry & Timeout Policy

Token Vault uses the following retry strategy for webhook calls:

Retry policy
Timeout:    10 seconds per request (30 seconds for /v1/proxy)
Retries:    2 retries (3 total attempts)
Backoff:    1s after first failure, 3s after second

Attempt 1:  Call webhook
Attempt 2:  Wait 1s → retry (only on 5xx or timeout)
Attempt 3:  Wait 3s → retry (only on 5xx or timeout)

No retry on 4xx errors (400, 401, 403, 410, 429)

A 429 is never retried: Token Vault reads your Retry-After header (clamped to 1–900 seconds) and propagates the backoff to the calling agent. After 5 consecutive failed calls to the same webhook host (timeout, 5xx, or 429), Token Vault opens a circuit breaker for 30 seconds to 10 minutes (doubling on repeated opens) and fails fast with a 503 instead of dialing your webhook. On the /v1/proxy path only connection-level failures (timeout/unreachable) count toward the circuit, since HTTP statuses there may be upstream responses passed through.

Extended timeout for /v1/proxy

The /v1/proxy endpoint has a 30-second timeout instead of 10 seconds. This accounts for upstream API latency, since the webhook must make a full HTTP round-trip to the upstream service before responding.

On this page