One governed endpoint for every application
Integrate once with a governed Vayon AI API. Your applications, services and automation call one endpoint; Vayon AI applies policy and Hybrid Routing and selects an eligible model — a caller's model preference is a hint, never an override of policy.
Govern. Route. Audit.
One governed integration surface
Applications, IDEs, internal services and automation integrate through one governed Vayon AI API to approved models.
Connecting systems is VAYON Core; developer tooling is an optional extension
The System Gateway, Integration Clients, the governed API surfaces, scopes and authentication, policy, Hybrid Routing and audit are all part of VAYON Core — connecting applications and business systems never requires a paid extension. The optional Developer AI Governance extension adds developer-facing tooling on top: the Developer Portal, IDE and VS Code integration, governed coding assistants — including third-party coding clients pointed at the gateway — and secure-coding controls and profiles.
Vayon AI for VS Code
A governed AI coding assistant inside VS Code. It works with your workspace and project context and surfaces sensitivity and model-access feedback; review, diff and Review & Apply keep you in control before changes land. Routing and policy stay with the Vayon AI Gateway, not the client. Part of the Developer AI Governance extension.
Claude Code through Vayon AI
Claude Code can be routed through Vayon AI using the supported Anthropic-compatible path. Requests are governed by organizational policy and the configured coding-client identity. Per-person attribution depends on the supported identity path available for that deployment: a coding client authenticated by a static integration key is attributed to the client and its workstation, not to an individual. Claude Code is a third-party tool, not a Vayon AI product.
Codex through Vayon AI
Codex connects over the OpenAI-compatible path, via a model-provider configuration pointed at the gateway. Model and provider hints cannot bypass organizational governance. Codex is a third-party tool, not a Vayon AI product.
Integration Clients and scoped access
Integration Clients authenticate with client credentials and receive a short-lived opaque token; scopes unlock specific governed endpoints.
OpenAI-compatible and native Vayon AI API surfaces
Vayon AI exposes an OpenAI-compatible surface and native governed endpoints; the caller-supplied `model` field is treated as a hint, never an authority over policy.
Vayon AI runs inside your environment, so the host below is a placeholder for your own VAYON server. Credentials come from an Integration Client your administrator issues; what that client may do is set there, not in the call.
1 · Exchange client credentials for a token
Form-encoded, and `client_credentials` is the only grant type accepted.
curl -X POST https://vayon.example.internal/oauth/token \
-d grant_type=client_credentials \
-d client_id="$VAYON_CLIENT_ID" \
-d client_secret="$VAYON_CLIENT_SECRET"
# {"access_token": "...", "token_type": "Bearer",
# "expires_in": ..., "scope": "..."}2 · Ask what this client is allowed to do
The limits are the client's, not the caller's opinion of them.
curl https://vayon.example.internal/api/v1/integrations/me/limits \
-H "Authorization: Bearer $TOKEN"3 · Send a governed request — decision first
`options.dry_run` returns the governance decision without calling a model. It is the safest first call on any deployment, and it needs its own scope.
curl -X POST https://vayon.example.internal/api/v1/gateway/requests \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"input": { "text": "Summarise this quarter'\''s policy exceptions." },
"domain": "compliance",
"options": { "dry_run": true, "include_sources": true }
}'4 · Point an existing application at the gateway
An OpenAI-compatible surface, so a client that already speaks that protocol needs a base URL and a key rather than a rewrite. `model`, `temperature` and `max_tokens` are accepted and treated as hints — they never decide routing.
curl -X POST https://vayon.example.internal/v1/chat/completions \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"messages": [{ "role": "user", "content": "..." }],
"stream": false
}'What an OpenAI-compatible or Anthropic-compatible client can call
- POST /v1/chat/completions
- Chat completions, governed. Streaming is supported when the client asks for it.
- POST /v1/responses
- The Responses wire, governed exactly as chat completions are — the same policy, routing, redaction, quota and evidence. What differs is the body shape.
- POST /v1/messages
- The Anthropic-compatible Messages wire, for a coding client that speaks it.
- POST /v1/messages/count_tokens
- How large a request would be, answered inside your environment and never sent outside it. It is an estimate and the reply says so, because a number a client makes truncation decisions on must not pretend to a precision it does not have.
- POST /v1/embeddings
- Embeddings, governed. For a coding client this is not an unconditional route: the request carries the developer's own repository text, so the person's permissions are checked here as well — the control follows the content, not the word it is called by.
- GET /v1/models
- The model list a coding tool asks for before it will start. Deliberately not gated: refusing it would break a client at a point that tells it nothing.
Alongside these, the native surface adds the governed request paths, streaming, batch, file input, code generation, the integration self-description endpoints and agent-invocation status.
Where the model itself runs is an administrator's choice, not the caller's: an internal runtime such as Ollama, vLLM or LM Studio, any OpenAI-compatible internal endpoint, or an approved external destination such as GCP Vertex AI, AWS Bedrock or Azure OpenAI. The call above does not change.
Model preference is a hint, never an override
A caller-supplied provider/model is an input to Hybrid Routing. It never overrides policy, sensitivity or authorization.
Hybrid Routing and policy enforcement
Requests are routed to the Best Eligible Fit; policy, sensitivity and context-egress gates still apply.
Streaming, batch and internal file support
Governed streaming (SSE), batch (JSON/NDJSON) and an internal File API are available where repository truth supports them; external execution paths are default-OFF.
Test how a request is classified
Developers can inspect classification and egress verdict before integrating — including sensitive requests that stay internal.
Developer documentation and test harness
A developer integration guide and test harness support onboarding. Coding tools that speak a supported coding-client protocol — including the OpenAI-compatible one — can be routed through the governed path; a tool with a proprietary protocol cannot, and the product names which is which rather than implying universal coverage.
Point one application at the governed endpoint
The integration is one endpoint and one credential. Bring the application you would connect first.