feat(integrations): add support for openrouter

[tonydzi]

Describe the problem and your solution

• add support for openrouter

OpenRouter is a unified, OpenAI-compatible API in front of hundreds of LLMs from many providers.

Provider config

• auth_mode: API_KEY, sent as authorization: Bearer ${apiKey}
• base_url: https://openrouter.ai/api
• verification: GET /v1/key (docs). This endpoint requires a valid key; /v1/models is public and would accept any key, so it was not used.
• credential pattern ^sk-or-v1-[a-zA-Z0-9]+$, doc_section points to the connect guide

Files: providers.yaml, docs/api-integrations/openrouter.mdx, docs/api-integrations/openrouter/connect.mdx, docs/docs.json, generated snippets (npm run docs:generate), regenerated llms.txt / llms-full.txt / api-catalog.txt, and the official OpenRouter glyph from https://openrouter.ai/brand as the logo.

Testing

• npx tsx scripts/validation/providers/validate.ts: ✅ All providers are valid (also confirmed it fails with openrouter SVG file not found when the logo is removed)
• prettier --check packages/providers/providers.yaml: passes
• Live check of the verification endpoint against https://openrouter.ai/api/v1/key: real key → 200, bogus sk-or-v1-… key → 401, no key → 401
• Not run: local docker compose up end-to-end connection and mintlify broken-links (all internal links in the new pages point to existing docs files). No connect-form screenshot is included.

I use OpenRouter daily. Built with Claude Code as implementation collaborator; reviewed and verified by me.

— Anton Dziatkovskii · github.com/tonydzi

🤖 Generated with Claude Code

[cubic-dev-ai]

No issues found across 10 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}

[tonydzi]

Wrote up why this PR verifies keys through /v1/key and not /v1/models: https://dev.to/tonydzi/adding-openrouter-to-nango-why-v1models-accepts-a-fake-key-2p98

Short version: OpenRouter's /v1/models is public by design — it returns 200 for a fake key, for a well-formed fake key, and with no Authorization header at all. /v1/key returns 401 / 401 / 200 (fake / none / real), which is the whole contract a verification endpoint needs.

If it is useful, I am happy to run the same three-curl check (fake key, no key, real key) against the other providers in the catalog that verify through a /models endpoint and report which of them are actually public.

— Anton Dziatkovskii · github.com/tonydzi

[tonydzi]

Live verification done today (2026-09-24) with a real OpenRouter key:

• GET https://openrouter.ai/api/v1/key with Authorization: Bearer <key> → 200
• same endpoint with a deliberately wrong key → 401 (the verification endpoint discriminates)
• the real key matches the PR's pattern: '^sk-or-v1-[a-zA-Z0-9]+$'

Credential contract checked end to end against the live API. If the full local nango dev run is still required beyond this, say so and I'll name it as the open blocker rather than let the PR sit quietly.

—
github.com/tonydzi

[hassan254-prog]

This is being handled in another pr; #7710