OpenRouter

Call models from the OpenRouter catalog through your Verdictan gateway. Verdictan applies your policies first, and then OpenRouter picks the upstream provider that serves the model.

Use the full provider/model ID from the OpenRouter catalog, in the configuration and in each request. Verdictan does not add or resolve the provider prefix.

Before you start

• A working gateway from the quickstart.
• An OpenRouter API key, and one model ID from the OpenRouter catalog.
• The gateway startup command, and a separate application token for test requests.

Configure the provider

Set base_url to the OpenRouter origin, https://openrouter.ai, without /api. The gateway adds /api/v1/... itself.

policy-config.yaml

pack:
  name: openrouter-integration
  version: 1.0.0
  enabled: true
policies:
  chain:
    - prompt-injection
providers:
  targets:
    - id: openrouter-primary
      provider: openrouter
      model: "replace-with-provider/model"
      base_url: https://openrouter.ai
      secret_key_ref:
        env: VERDICTAN_OPENROUTER_API_KEY

Chat Completions go to /api/v1/chat/completions with the key from VERDICTAN_OPENROUTER_API_KEY as a Bearer token.

Start and verify

With CLI 0.1.14 or later, you can deploy the OpenRouter target through its agent. Wait for In sync, then test the complete model ID below.

With the quickstart in Docker, follow the container steps instead of steps 1 to 3.

1. In the gateway terminal, set the key and lint the file:

   export VERDICTAN_OPENROUTER_API_KEY="<provider-api-key>"
   verdictan policy lint --file policy-config.yaml

2. Restart the test gateway with the key in its environment.

3. Deploy the file to the test agent in Configurations. If that agent already runs pack.version 1.0.0, increase the version first. Then wait for the gateway log line connected read model refresh applied updated config with your version as config_version. Try the change on a test gateway has the steps.

4. In a second terminal, send a request with the full model ID:

   export VERDICTAN_CLIENT_TOKEN="<application-token>"
   curl --fail-with-body http://127.0.0.1:41002/v1/chat/completions \
     -H "Authorization: Bearer ${VERDICTAN_CLIENT_TOKEN}" \
     -H "Content-Type: application/json" \
     -d '{"model":"replace-with-provider/model","messages":[{"role":"user","content":"Reply with Hello."}]}'

choices[0].message.content contains the reply, and the request appears in History when capture is on, or in the delivered events.

Supported requests

Request	Support
Chat Completions	Yes. Streaming, tools, and response_format work if the model supports them.
Responses, Messages, audio	The adapter maps these paths, but they are not tested against OpenRouter. A working chat request does not prove them.
Embeddings, image input	No

Failure behavior

Problem	What to check
401 from the gateway	The application token is active, and the key is set on the gateway host.
Provider authentication error	VERDICTAN_OPENROUTER_API_KEY is set in the gateway process. Restart the gateway.
404 from OpenRouter	base_url is https://openrouter.ai, without /api.
Model not found	The request uses the full provider/model ID, and it matches the target.
capability.unsupported_family	The request is Chat Completions.
Provider 402, 429, or another upstream error	The response body, your OpenRouter credits, and rate limits. See Error Handling.

Limits

• Model names, prices, rate limits, and data terms are in the OpenRouter documentation.
• OpenRouter picks the upstream provider, region, and data terms for each model after Verdictan policies run. Read OpenRouter's routing rules for your model.
• Streaming, tools, and structured output vary by model. Test each one with your model.
• A listener on a non-loopback address needs TLS and network controls.

Next steps

• Provider Configuration: target fields, routing, and fallback.
• Runtime Request Families: request families and their policy stages.