EORTC coordinates clinical cancer research across a network of European hospitals. Route the trial-data pipelines, scripts, and containers your study runs on through two fixed static EU IPs with one HTTPS_PROXY variable.
# on your analysis VM or container
export HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
export NO_PROXY=localhost,127.0.0.1
import requests
# requests and httpx read HTTPS_PROXY
r = requests.get(
"https://api.partner-institute.eu/cohort",
headers={"Authorization": "Bearer ..."})
Clinical research runs on trust between institutions, and a lot of that trust is expressed in network rules. Your workloads keep moving; the allowlists do not.
Hospital and university networks gate automated access to their systems. A firewall exception, an API allowlist entry, a vendor onboarding form: each one is pinned to a source address. An automation whose egress changes with every deploy cannot be pinned, so it cannot be approved.
The same study touches a university cluster one month, a cloud VM the next, and a container somewhere else after that. Each environment exits through a different address, so every institution you exchange data with sees a different visitor, and yesterday's exception stops matching.
EORTC shares data and samples through a formal request program, not a developer API. The engineering happens on your side: analysis pipelines, licensed quality-of-life instruments, and EDC-side automations calling institutional and vendor systems, several of which filter by source address.
GDPR makes the path your data takes part of the compliance conversation. When a script running in a non-EU region calls a European institutional endpoint, the DPO and the ethics review will ask why. A detour outside the EU is exactly the kind of question a research project does not need.
Your Research Workloads
pipelines, scripts, containers
HTTPS Proxy
(Static EU IP)
Research Systems
with IP allowlist
Whether your workload runs on a university cluster, a cloud VM, or a container in a pipeline, it presents the same two EU addresses to the outside world. Get the address pair approved once, and it holds for the life of the study.
Teams doing clinical research work in and around EORTC studies who need the institutions they call to recognize them.
Your site's automations push and pull from EDC platforms, registries, and partner systems. Give every job the same stable egress identity instead of a new one per server.
Data and samples requested through EORTC's sharing program land in your environment for analysis. The pipelines you build around them still call institutional and publisher APIs that care where you come from.
Digital data collection built on licensed EORTC instruments runs as software, and software has an egress address. Make it a stable one before the hosting changes underneath it.
You approve the exceptions researchers ask for. Two fixed addresses that outlive any single VM turn each approval into a one-time conversation instead of a recurring one.
Set the variable in the environment your workload already runs in. The next process or container that starts egresses from the fixed pair.
Add the export to your shell profile so every session and job launcher picks it up, then source it or reconnect. Keep the credentials out of committed files.
# ~/.bashrc or ~/.zshrc on the machine
export HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
export NO_PROXY=localhost,127.0.0.1
# apply without reconnecting
source ~/.bashrcFor Docker-based workloads, pass the variable when the container starts. The same pattern applies to pipeline task definitions: provide the environment, the app reads it.
# docker run
docker run -e HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443 \
-e NO_PROXY=localhost,127.0.0.1 \
your-analysis-image
# docker-compose.yml
services:
pipeline:
environment:
- HTTPS_PROXY=${OGW_PROXY_URL}
- NO_PROXY=localhost,127.0.0.1requests and httpx read HTTPS_PROXY from the environment automatically. No code changes.
import os
import requests
# picked up from HTTPS_PROXY in the environment
r = requests.get(
"https://api.partner-institute.eu/cohort",
headers={"Authorization":
f"Bearer {os.environ['PARTNER_TOKEN']}"},
)Node's fetch does not follow proxy environment variables on its own. Wire it explicitly with https-proxy-agent.
const { HttpsProxyAgent } = require('https-proxy-agent');
const agent = new HttpsProxyAgent(process.env.HTTPS_PROXY);
const res = await fetch('https://api.partner-institute.eu/cohort', {
headers: { 'Authorization': 'Bearer ..' },
agent,
});Whitelist both IPs, everywhere
Your account includes two fixed IP addresses. Add both to every allowlist you maintain. Traffic balances across the pair, and if one proxy node drops out the other keeps your workloads online, whatever machine or cluster they run on.
📖 Complete Documentation: For detailed examples, error handling, and other Python libraries, see the Python SSL Proxy Guide, Node.js Guide, and all other language guides.
EORTC is a European organisation coordinating research across European hospitals, under GDPR, in the era of the European Health Data Space. OutboundGateway keeps the outbound leg consistent with that reality: European data centres, GDPR-conscious handling, and no detour through overseas infrastructure just to reach an institutional endpoint.
Traffic to institutional and partner systems leaves from EU addresses through EU infrastructure, which simplifies the data-processing story you tell ethics committees and auditors.
European research data stays on a European path. No part of the outbound route depends on a non-EU provider.
Two stable addresses make your integrations auditable: institutions can pin exactly where your traffic comes from, and it stops moving between environments.
Scripts, pipelines, and containers all present the same pair, with automatic failover between them.
Move between clusters, VMs, and containers freely. The approved addresses belong to your account, not to any machine.
European data centres and a GDPR-conscious setup, so egress matches where your research data already lives.
Python, Node, and any runtime that honours HTTPS_PROXY. One pair covers scripts, services, and pipeline tasks alike.
TLS passthrough means the proxy never sees plaintext. Tokens, payloads, and study data remain private.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
Stop renegotiating network exceptions every time the compute moves. One environment variable, and every script, pipeline, and container in your study egresses through the same two fixed EU IPs.
€19/month starter plan • 7-day refund policy • Direct founder support
EORTC does not operate a public developer API. Access to data and samples collected in its research goes through the Data and Sample Sharing program: qualified researchers submit a proposal via online forms, under a published Data Sharing Policy and Terms of Use, with questions handled by datasharing@eortc.org. The proxy is not about reaching EORTC systems; it gives the workloads you run a stable outbound identity for the institutional and vendor systems that do filter by source address.
Because the approvals around your work are pinned to addresses while your compute is not. Hospital and university IT, EDC vendor onboarding, and partner-institution integrations commonly register the source address an automated connection will come from. Move your pipeline from a cluster to a cloud VM, or rebuild a container host, and that registration silently stops matching. Two fixed egress IPs make the registration permanent.
For Python workloads using requests or httpx, no: they read HTTPS_PROXY from the environment automatically, so exporting the variable on the machine or in the container is enough. Node's built-in fetch ignores proxy environment variables, so Node services need a small change with https-proxy-agent, shown in the implementation above.
Happy to talk through how a two-IP EU egress fits your study setup, from a single analysis VM to pipelines spread across clusters and clouds.
Contact Our Founders →