Fix API connection errors before an HTTP response

Which layer failed?

A missing request row is a clue, not proof of a particular cause. The client might fail before reaching the gateway, while rejected requests, log filters or recording delays can also explain a missing row. Start with what the client actually received.

Fix Invalid URL without guessing the path

Copy only the URL into the API Host or Base URL field. Check for a pasted Markdown link, surrounding quotes or brackets, a duplicated https:// prefix, and unexpected whitespace. An empty or invalid base can make the JavaScript URL constructor throw before any network request. A syntactically valid URL can still point at the wrong API route.

• These values apply to the configurations in the linked integration guides. Other providers, client versions or API types can use different fields.
• Keep the API key in its dedicated secret field. A key does not belong in the URL.
• After correcting the field, restart or reload the client if it reads configuration only at startup. Confirm the actual request path before changing /v1 again.

Check DNS on the affected device

Run these read-only lookups on the same device and network where the app fails. Record the resolver and returned addresses, or the exact lookup error. router.one and api.router.one are different hostnames: the website opening does not establish that the API hostname resolves.

nslookup api.router.one
nslookup router.one

• Compare with a second network or an approved alternative resolver. Different answers alone do not prove interference: caches and routing can legitimately differ.
• A successful nslookup does not prove the app uses the same resolution path. Check local hosts overrides, the app's proxy settings, VPN/TUN state, and its runtime resolver. Node.js dns.lookup uses the operating system's lookup facility.
• ENOTFOUND alone does not establish that the domain expired or the provider is down. EAI_AGAIN suggests a temporary lookup failure; retry briefly, then investigate recurring failures.

Probe HTTPS without sending an API key

This macOS/Linux command makes a read-only GET to the model-list path. It sends no API key and requests no generation. -q skips curl's default config file; certificate verification stays enabled and redirects are not followed. The response body is discarded: first inspect the status, Content-Type and Location headers. Remove --output /dev/null to inspect the body if the response source remains unclear. On Windows PowerShell, use curl.exe, put the command on one line and replace /dev/null with NUL.

curl -q --silent --show-error --connect-timeout 10 --max-time 20 \
  --dump-header - --output /dev/null \
  --write-out 'http_code=%{http_code} remote_ip=%{remote_ip}\n' \
  https://api.router.one/v1/models

Separate TLS, proxy and app differences

For certificate failures, first verify the device clock and the configured hostname, then update the app or runtime's trusted certificate store through its supported process. On a managed network, ask IT to verify the inspection certificate and trust configuration. A certificate error identifies a failed verification, not who caused it.

Browser apps and CORS

When code calls the API with the browser's fetch, such as a web page or the window of a web-based desktop app, the browser first sends a preflight OPTIONS request for a POST that carries an Authorization or x-api-key header and a JSON body. Since 2026-10-02, api.router.one answers that preflight on its /v1 endpoints with HTTP 204, Access-Control-Allow-Origin: * and the request headers the browser listed, x-stainless-* and anthropic-dangerous-direct-browser-access included (checked 2026-10-03), and the page can read the gateway's own error responses, such as the HTTP 401 for a bad key. If the browser still reports a CORS error, check the host name and the scheme first: the API host is https://api.router.one, and a preflight sent to the router.one website host gets HTTP 404 with no CORS headers; an http:// URL is answered with a redirect, which a preflight cannot follow. A wrong path on api.router.one comes back as a readable HTTP 404, not a CORS error. An error produced before the request reaches the gateway carries no CORS headers either and also shows up as a CORS error, so in that case check any proxy, extension or client setting that changes or intercepts the request.

Collect evidence that support can use

After you can reach the expected HTTPS service, follow the client's integration guide for one authenticated text request and match the result with Dashboard → Logs. If the problem persists, send this small evidence set through the contact page:

• Time and timezone; device OS; app name and version; affected region and network.
• Configured hostname and API path, selected protocol and exact model ID, with any credentials or private query parameters removed.
• Exact error code and message; HTTP status, response type and request_id if present. A failure before HTTP may have no request_id.
• DNS result and key-free curl result; whether a second network or another client behaves differently.
• Do not include API keys, Authorization headers, cookies, proxy passwords or private prompts. Redact these before sharing screenshots or logs.

Scope and sources

Reviewed September 9, 2026 against the URL Standard, Node.js and libuv error documentation, and curl's command and certificate documentation linked below; the CORS section was added on October 3, 2026 from preflight checks of api.router.one, the OpenAI and Anthropic TypeScript SDK sources and Chrome's extension docs. The commands are diagnostic recipes, not a live availability report. A successful connectivity probe verifies only its own device, network, hostname and request at that time.

Connection troubleshooting FAQ