Calling Mistral AI for chat, embeddings, or Codestral from containers or serverless? Every redeploy shifts the IP, breaking IP-restricted keys and GDPR audits. Route your Mistral API traffic through two fixed static EU IPs.
import requests
# leaves through static EU IP
# HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
r = requests.post(
"https://api.mistral.ai/v1/chat/completions",
headers={"Authorization": "Bearer KEY"},
json={"model": "mistral-small-latest"}
)
Mistral is French and EU-AI-Act relevant, so the where-your-calls-come-from question matters. Rotating egress makes it hard to answer.
Teams lock their Mistral API key to specific IPs. When a pod, container, or function moves to a new address, requests to api.mistral.ai come back unauthorized, and chat and embeddings calls silently stop working.
Cloud functions and Kubernetes assign a fresh outbound IP on each deploy and autoscale. RAG pipelines, chat features, and Codestral completions that worked at noon fail at midnight with no code change, because the source IP shifted underneath them.
Processing prompts and model output is data handling under GDPR, and the EU AI Act adds transparency duties. Auditors want a documented, stable egress for AI calls, not an address list that changes every release.
An app often mixes Mistral Small, Large, embeddings, and Codestral across services. Each call from each environment rides a different rotating IP, so there is no single, predictable address to whitelist or audit.
"Which IP addresses do our Mistral API calls come from?"
You want one fixed answer, not "it depends which pod served the request."
Your AI app
HTTPS Proxy
(Static EU IP)
Mistral API
Mistral sees your calls from the same pair of EU addresses every time, whether it is chat, embeddings, or Codestral. Two IPs back the account, and if one is down the other takes over.
api.mistral.ai, with no SDK rewrite.
mistralai SDK, requests, fetch, and anything that honours the standard proxy environment variables.
Building chat, RAG, or code features on Mistral who need their API key to keep working through every container restart.
Shipping EU products that use Mistral and need IP-whitelisted, GDPR-aligned access across dev and prod.
Running Mistral in production with strict network policies that require a known, stable source address.
Accountable for where AI prompts and output are sent, who want a documented EU egress rather than a moving address.
Set HTTPS_PROXY and your Mistral calls leave through your fixed EU IP. No rewrite to your chat or embeddings code.
Drop HTTPS_PROXY into your environment and requests honours it automatically. The chat-completions call below already leaves through your static IP.
# .env or shell
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
MISTRAL_API_KEY=your_api_key
import os
import requests
# requests reads HTTPS_PROXY from the environment automatically
r = requests.post(
"https://api.mistral.ai/v1/chat/completions",
headers={"Authorization": f"Bearer {os.environ['MISTRAL_API_KEY']}"},
json={
"model": "mistral-small-latest",
"messages": [{"role": "user", "content": "Summarize this document."}],
},
)
print(r.json()["choices"][0]["message"]["content"])
Node's fetch doesn't read the env var on its own, so pass the proxy explicitly with https-proxy-agent.
// .env or shell
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
MISTRAL_API_KEY=your_api_key
const { HttpsProxyAgent } = require('https-proxy-agent');
const agent = new HttpsProxyAgent(process.env.HTTPS_PROXY);
// This POST leaves through your static EU IP
const res = await fetch('https://api.mistral.ai/v1/chat/completions', {
method: 'POST',
headers: {
'Authorization': `Bearer ${process.env.MISTRAL_API_KEY}`,
'Content-Type': 'application/json',
},
body: JSON.stringify({
model: 'mistral-small-latest',
messages: [{ role: 'user', content: 'Summarize this document.' }],
}),
agent,
});
console.log(await res.json());Set the variable in your platform config, the same approach in every environment. Never paste the proxy string in plaintext.
# Docker Compose: load a .env file
services:
app:
env_file:
- .env
# Kubernetes: pull it from a Secret
env:
- name: HTTPS_PROXY
valueFrom:
secretKeyRef:
name: outboundgateway-proxy
key: proxy-url
# AWS Lambda: function environment variables
HTTPS_PROXY=${OUTBOUNDGATEWAY_PROXY_URL}Two IPs, so a chat call doesn't depend on one box
Your account comes with two static IP addresses (for example 51.xx.xx.10 and 51.xx.xx.11). Register both against your Mistral key. If one proxy node is briefly unavailable, traffic shifts to the other, so an overnight redeploy isn't the thing that breaks your AI features.
📖 Want the longer version? Worked examples, error handling, and other languages are in the Python SSL Proxy Guide, Node.js Guide, and the rest of the docs.
Mistral is a French company and an EU AI Act subject, so where your calls leave from is part of the compliance story.
The proxy runs in EU data centres, so your Mistral API traffic stays within European borders rather than wherever a container happens to be scheduled.
Processing prompts and model output is data handling. A stable, documented EU egress is the kind of detail both a GDPR review and an AI-governance review ask for.
Traffic doesn't bounce through US infrastructure on its way to Mistral, which removes a common wrinkle from GDPR data-transfer reviews.
When a reviewer asks where your Mistral calls originate from, the answer is two fixed EU addresses, not a list that changes every release. The failover pair covers maintenance windows.
Two addresses to register against your key, with automatic failover, so your traffic isn't riding on a single point of failure.
Add one env var and your existing mistralai SDK, requests, or fetch code starts routing through the proxy.
European data centres and a GDPR-conscious setup, so your Mistral traffic leaves from a predictable EU address.
Mistral Small, Large, embeddings, and Codestral all go out through the same stable pair of IPs.
TLS passthrough means the proxy can't read your traffic. Prompts, completions, and your bearer token stay private the whole way.
Starting from €29/month. Flexible plans for every scale. Cancel anytime.
Stop letting pod restarts and autoscaling decide which IP your chat and embeddings calls come from. Put Mistral behind one stable, GDPR-conscious address.
€29/month starter plan • 7-day refund policy • Direct founder support
Yes. The mistralai Python and JavaScript SDKs use standard HTTP under the hood, so setting HTTPS_PROXY (and routing through the proxy) applies to their calls without changing how you construct a client or a request. You can also call api.mistral.ai directly with requests or fetch and get the same effect.
That's the main reason teams add the proxy. Mistral keys can be tied to specific source IPs, but containers and functions get a new address on every deploy, which would normally break that restriction. By routing outbound calls through a fixed pair of EU addresses and registering both against the key, the key keeps authorising requests no matter how often your deployment restarts.
Yes. The proxy isn't endpoint-specific. Anything your app sends to api.mistral.ai (chat completions, embeddings, Codestral code completions, function calling) leaves through the same fixed pair of EU IPs, so one whitelist covers the whole model lineup.
Happy to talk through how a two-IP egress fits your specific Mistral setup, whether it's chat, RAG, or Codestral.
Contact Our Founders →