SilkRouter API Troubleshooting: Errors and Fixes

Fast triage

Start troubleshooting by separating authentication, funding, model choice, request shape, and network behavior. Guessing from the error message alone often wastes time.

Confirm the call is server-side, the SilkRouter key is present, the base URL is correct, and the requested model ID is supported for the account.

Common errors

Authentication failures usually mean the wrong key, missing bearer header, expired key, or a provider key used where a SilkRouter key is expected. Low-balance failures mean the account needs credits before traffic continues.

Unsupported model errors usually come from a typo, stale model ID, or assuming provider-native IDs map one-to-one. Timeout and rate-limit errors need bounded retries, not infinite loops.

• 401 or 403: check API key, environment, and server-side secret loading.
• 402 or low balance: review credits before retrying.
• 404 or unsupported model: verify the exact routed model ID.
• 429 or timeout: apply backoff and inspect recent traffic.
• 400: validate message format, JSON body, and token limits.

CORS and browser issues

Do not expose API keys in browser code. If a frontend call fails with CORS or missing authorization, move the request behind a backend endpoint.

The browser should call your app server. Your app server should call SilkRouter, apply product rules, and return only customer-safe data to the UI.

Monitoring after a fix

After the immediate fix, review logs for repeated failures, retry spikes, and unusually long outputs. A single error can point to a larger routing, prompt, or balance issue.

Keep a short internal runbook with known model IDs, key locations, retry policy, and the owner for credits or account changes.