Vidal is the clinical drug database behind prescribing and interaction checks across French hospitals. Its enterprise API access is governed by network parameters, so send every vidal.fr lookup out through two static EU IPs your hospital IT has already approved.
# requests picks this up automatically
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
requests.get('https://api.vidal.fr/rest/api/packages',
auth=(VIDAL_APP_ID, VIDAL_APP_KEY))
A drug interaction check happens at the moment of prescribing, inside hospital infrastructure, against a database licensed under contract. Every layer of that setup assumes you know exactly where the request comes from.
Vidal's REST API is a licensed B2B service provisioned through their gateway, and enterprise agreements govern access with network and IP controls rather than open self-service signup. When your workload's exit address changes after every deploy, the parameters recorded at provisioning no longer match reality and calls stop at the gateway.
Interaction and contraindication checks fire while a clinician is writing the prescription. A request that fails there is not a background retry, it is a doctor staring at a spinner and reaching for the paper compendium. Egress that silently breaks after a platform rollout does exactly that.
The hospital's security team enforces what may leave the clinical network and to whom. Asking them to clear a moving pool of cloud addresses is a non-starter; asking them to clear two named European addresses is a form they have signed before.
Prescribing queries can be tied to a patient context, which puts them in scope for GDPR and the French regime for health data. Auditors and hospital partners expect a documented, stable path for every external call a clinical system makes, not an exit that depends on which instance happened to scale up.
Your clinical software
CPOE, pharmacy, CDS modules
HTTPS Proxy
(Static EU IP)
api.vidal.fr
drug database REST API
Package searches, monographs, interaction checks: whatever your modules request from Vidal leaves through the same two European addresses. Register the pair once with the hospital and with Vidal, and every rollout, scale-up, and migration afterward leaves the approval untouched.
HTTPS_PROXY per environment and Python services pick it up with zero code edits; Node services attach one agent.Two named European addresses to put on the proxy exception form and in the Vidal provisioning record, instead of a range that shifts under their feet.
The Vidal REST API is ordinary HTTPS: one environment variable for Python, one agent for Node, one env file for containers. Your integration code stays as licensed and tested.
Vidal is a French provider and the proxy egress sits in EU data centres, so clinical queries to a French drug reference never cross outside the Union.
Teams whose software touches the Vidal drug database and needs the network side of the integration to look as controlled as the clinical side.
Editorial teams embedding Vidal content in CPOE and prescribing tools, where each client deployment means another hospital network to register your egress with.
Pharmacy suites checking substitutions, dosages, and interactions at dispensing time, where a failed lookup directly slows down patient care.
CDS engines enriching rules with Vidal's referential data on SNOMED CT-coded medications, running scheduled syncs and on-demand checks side by side.
Groups operating sites across France and neighbouring countries, collapsing many per-site egress points into one address pair that satisfies every facility's firewall.
Aim your existing HTTP stack at the proxy and every request to api.vidal.fr changes origin.
The requests library consults HTTPS_PROXY on its own, so the module you already licensed and tested keeps its code untouched. Keep your app_id and app_key in the environment, never in the source.
import os
import requests
resp = requests.get(
"https://api.vidal.fr/rest/api/packages",
params={"q": "amoxicilline"},
auth=(os.environ["VIDAL_APP_ID"], os.environ["VIDAL_APP_KEY"]),
timeout=15,
)
# HTTPS_PROXY from the environment is honoured automatically
In Node, route fetches through the proxy with https-proxy-agent.
import { HttpsProxyAgent } from "https-proxy-agent";
const agent = new HttpsProxyAgent(process.env.HTTPS_PROXY);
const res = await fetch("https://api.vidal.fr/rest/api/packages?q=doliprane", {
headers: { Authorization: `Basic ${btoa(process.env.VIDAL_APP_ID + ":" + process.env.VIDAL_APP_KEY)}` },
agent,
});
Credentials belong in the environment or your secret store, not next to the code.
# docker-compose.yml
services:
prescribing-api:
build: .
env_file: .env # HTTPS_PROXY=..., VIDAL_APP_ID=..., VIDAL_APP_KEY=...
# Kubernetes
env:
- name: HTTPS_PROXY
valueFrom:
secretKeyRef:
name: outboundgateway
key: proxy-url
Put the pair in the provisioning record
Your account includes two fixed European addresses designed to cover for each other. Enter both in the network parameters agreed with Vidal and in each hospital's firewall request: whichever node is active, the source their gateways observe stays inside the list you declared.
📖 Complete Documentation: For detailed examples, error handling, and advanced configurations, see the all guides.
Drug database queries can carry patient context, and in a hospital setting that context is regulated on both sides of the connection.
Prescribing and dispensing queries that reference a patient fall under GDPR and France's health data rules. Egress from EU data centres keeps the processing story you tell auditors simple.
The proxy forwards the encrypted session to Vidal untouched. Credentials, patient context, and query terms stay sealed between your software and api.vidal.fr.
Two European IPs that stand in for each other, so the pair in the Vidal record and the hospital firewall is always the pair in service.
One env var for Python, one agent for Node, one env file for containers. No SDK fork, no code fork, no revalidation of your integration.
Sealed TLS transits the proxy unread; credentials and clinical context stay between you and Vidal.
Egress inside the Union for queries to a French drug referential, keeping the path domestic where it matters.
Staging, pilot hospitals, and production all present the same source, so logs and approvals read the same everywhere.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
Give the hospital and the provisioning record the same two-line answer: fixed European addresses, mutual failover, every drug lookup behind them.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
Vidal's REST API is a licensed service reached through their gateway with the credentials issued for your project (app_id and app_key, provisioned via editeurs@vidal.fr), and enterprise agreements govern access with network and IP parameters. A fixed address pair keeps what you declared at provisioning aligned with what actually connects, whichever platform your software runs on.
The proxy adds one hop inside an EU data centre and otherwise forwards the sealed TLS session, so the lookup path stays short. Interaction and dosage checks fire at the moment of prescribing, and keeping that path predictable matters as much as keeping it fast: a stable egress means no surprise gateway rejections at the bedside.
No. Each deployment sets the same HTTPS_PROXY value, and all of them then share your account's two European addresses. That turns N per-site firewall conversations into one address pair every hospital IT department can approve once, no matter how many instances you later roll out or upgrade.
Glad to walk through your Vidal integration, your per-site deployments, and how one fixed EU pair simplifies each hospital's network approval.
Contact Our Founders →