Skip to main content
Select an available model and generate a text response using the OpenAI-compatible chat-completion endpoint.

​
Before you start

You need curl, jq, and an API credential authorized for inference. The examples attribute the request to support-assistant; replace that reference with your project.

​
1. Discover model IDs

Call GET /ai/v1/models:
list-models.sh
Choose a model that supports chat completions. Chat Completions serves OpenAI and open-weight models only. Calling it with a Claude or Gemini model returns 404; see request formats by model family. The model discovery reference describes capabilities and deployment metadata. Use a returned ID rather than guessing a model or version name.

​
2. Generate a response

Set MODEL_ID, then call POST /ai/v1/chat/completions:
generate-response.sh
The model ID selects the deployment. Project policies, credential limits, and spending checks still apply to the request.

​
3. Read the answer

Inspect the response before extracting the assistant message:
read-response.sh
For this text-only example, expect an assistant answer in the first choice. Inspect the error body if the request fails, or finish_reason if generation ends unexpectedly. If the request returns 403, inspect the error body and choose a model permitted by the project policy. For a request naming a project, review the project inference policy and its inherited account rules. For serving-location restrictions, see Use models served outside the EU. This is a direct inference request. To execute a configured agent and track its run history, follow Run an agent. To record runs from your own agent code, follow Connect your own agent runtime.

​
Use models served outside the EU

Choose a discovered model permitted by the deployment’s serving restrictions and the applicable model policies. A request naming a project, including this guide’s example, follows that project’s policy and the account rules it inherits. An account API key that names no project follows its account policy. While a deployment retains the legacy EU-only default or a stored project tier restriction, choosing a non-EU model can return policy-tier-denied. Changing default_model does not record non-EU consent or remove a stored tier restriction. Account model-policy changes do not override the project policy. For an EU-only deployment, select a model whose discovery metadata reports veryfront.processing as eu, then retry. Older API revisions can expose separate standard-tier consent operations. Where those operations exist, project-selected requests require project consent; account consent applies only to an account API key naming no project. Use the operations documented by that deployment’s API reference. If consent operations are absent, ask the deployment administrator to complete the policy migration and verify any remaining project restrictions. The model-policy request below does not replace consent.

​
Configure the account model policy

An account policy selects allowed and denied models and an optional default model. Projects inherit these rules and can only narrow them. Discover model IDs before configuring a policy. Use a signed-in session as an account owner or administrator with permission to manage account settings. API keys are refused regardless of their scopes. Copy the account ID from the account’s settings and use the session token from the authToken cookie of a browser signed in to Veryfront. Read the current policy with GET /accounts/{account_id}/inference-policy. To change the default model, call PATCH /accounts/{account_id}/inference-policy:
set-account-model-policy.sh
The response reports the account’s models rules and default_model. Fields omitted from the request retain their stored values. To remove the account model policy, call DELETE /accounts/{account_id}/inference-policy; this returns {"ok":true} and restores the built-in model defaults.

​
API references