Mistral AI

Call Mistral chat and embedding models through your Verdictan gateway. Your Mistral key stays on the gateway, and your application calls the gateway with its application token.

Each target serves one model. For chat and embeddings, configure one target for each, and the gateway picks the target whose model matches the request.

Before you start

• A working gateway from the quickstart.
• A Mistral API key, and the chat model ID you want to use.
• The gateway startup command, and a separate application token for test requests.

Configure the provider

policy-config.yaml

pack:
  name: mistral-integration
  version: 1.0.0
  enabled: true
policies:
  chain:
    - prompt-injection
providers:
  targets:
    - id: mistral-chat
      provider: mistral
      model: "replace-with-mistral-chat-model-id"
      base_url: https://api.mistral.ai
      secret_key_ref:
        env: VERDICTAN_MISTRAL_API_KEY
    - id: mistral-embed
      provider: mistral
      model: "mistral-embed"
      base_url: https://api.mistral.ai
      secret_key_ref:
        env: VERDICTAN_MISTRAL_API_KEY

The gateway appends the path for each request family, such as /v1/chat/completions or /v1/embeddings, and sends the key from VERDICTAN_MISTRAL_API_KEY as a Bearer token. Leave out the mistral-embed target if you only need chat.

Start and verify

To deploy from your terminal, use CLI 0.1.14 or later instead of the Console step. Check In sync. Then use the chat request below to verify the Mistral model.

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_MISTRAL_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 chat request:

   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-mistral-chat-model-id","messages":[{"role":"user","content":"Reply with Hello."}]}'

5. If you kept the embedding target, send an embeddings request:

   curl --fail-with-body http://127.0.0.1:41002/v1/embeddings \
     -H "Authorization: Bearer ${VERDICTAN_CLIENT_TOKEN}" \
     -H "Content-Type: application/json" \
     -d '{"model":"mistral-embed","input":["Hello"]}'

The chat reply is in choices[0].message.content, and the vectors are in data[].embedding. The chat request appears in History when capture is on, or in the delivered events.

Supported requests

Request	Support
Chat Completions	Yes. Streaming and tools work if the model supports them.
Messages	Translated to Chat Completions
Embeddings	Yes, with an embedding model
Responses, audio, image input, response_format, parallel tool calls	No

note

The gateway authenticates embeddings requests and applies provider access and budget rules, but your policy chain does not run on them. Only Chat Completions, Responses, and Messages go through the chain. Don't send text to /v1/embeddings that your controls must inspect first.

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_MISTRAL_API_KEY is set in the gateway process. Restart the gateway.
Model not found	The request model matches one target model.
Error from /v1/embeddings	The request names the embedding model, not the chat model.
Provider 429 or another upstream error	The response body and your Mistral limits. See Error Handling.

Limits

• Model names, prices, rate limits, and data terms are in the Mistral AI documentation.
• Streaming and tools 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.