Bitpanda's docs recommend restricting every API key to your server's specific static IP address. Route quotes, trades, and Earn stakes through two fixed static EU IPs, keep the IP allow list switched on, and stop exempting your bots from the rules.
# one variable, fixed egress for everything
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
# the allow list only trusts addresses you can
# predict, so give it two that never move
curl -s https://api.public.bitpanda.com/v1/portfolio \
-H "x-api-key: $BITPANDA_API_KEY"
Bitpanda's key creation includes an IP allow list toggle, and the security best practices say to pin each key to your server's static IP. Most platforms cannot name an egress address that survives the week, so the toggle stays off.
Creating a key walks you through scopes and an expiration date, then offers the IP allow list as optional but recommended. On egress that rotates, switching it on means the next deploy orphans the key, so teams leave it off and ship a key that works from anywhere.
For security reasons Bitpanda caps key lifetime at one year, which tells you how long these credentials are meant to live. Platform egress can change several times a day. Whatever address existed when you created the key is long gone before the key itself expires.
A trading quote you cannot accept before it lapses, a stake you cannot unstake on schedule: Trade (Write) and Earn (Write) are the scopes with money attached, and they are the calls an unlisted source address takes down first. Reads break loudly; writes break expensively.
The app rides the Public API, the desk trades on Fusion, agents talk to the MCP server, and each key carries its own allow list. Without one shared pair of addresses, every new workload multiplies the lists you have to keep current instead of pasting two IPs and moving on.
Your Platform
quotes · stakes · bots
HTTPS Proxy
(Static EU IP)
Bitpanda
api.public.bitpanda.com
Switch on the IP allow list Bitpanda recommends, paste both fixed addresses, and every request afterwards arrives from an origin the key already trusts, whichever runtime issued it.
HTTPS_PROXY once in your platform's environment; quote requests, stake actions and portfolio reads then leave from your fixed pair.x-api-key header and trade payloads stay encrypted past the proxy hop; we never see them.Bitpanda's own best practices say to restrict API access to your server's specific static IP address whenever possible. With a fixed pair, "whenever possible" becomes "always", and the safest configuration is also the one you never have to undo.
Because keys expire at most a year out, replacing them is a routine you will repeat forever. Each replacement key gets the same two addresses pasted into its allow list, and nothing about your egress story changes between rotations.
Public API for the product, Fusion for the desk, the MCP server for agents: one pair of addresses covers all of them, and your origin stays recognizable in Bitpanda's logs instead of dissolving into a cloud range. Trading on other venues? Our Bitstamp static IP guide applies the same pattern there.
Anyone holding a Bitpanda API key who wants the recommended IP allow list to be something they can actually enable.
Bots with Trade (Write) create quotes and accept them before the quotes lapse. Every accept has to leave from an address the key trusts, or the opportunity expires with the deploy that broke it.
Staking and unstaking actions run unattended with Earn (Write) scopes. Unattended schedules are precisely where a rotated egress address fails quietly, leaving a stuck stake and no alert.
Dashboards and reconciliation jobs pull Balances and Transaction scopes all day. Reads are low drama until they start failing on a new egress address, taking nightly reporting with them.
Bitpanda ships an MCP server at mcp.public.bitpanda.com, so agents acting on your account inherit the same key rules as any script. Pin their egress too, before they act from an address the key has never met.
One environment variable, and your Bitpanda traffic leaves from a fixed EU address.
Set the variable wherever your platform runs, then authenticate the way the docs describe: one x-api-key header on every request, no signing to implement at all.
# .env, ECS task definition, Kubernetes secret, wherever config lives
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
# read your portfolio, egressing from your static EU IP
curl -s https://api.public.bitpanda.com/v1/portfolio \
-H "x-api-key: $BITPANDA_API_KEY"requests reads HTTPS_PROXY from the environment automatically, so a scoped key plus one env var is the whole integration.
import os, requests
# key needs the Earn (Read) scope for this call
r = requests.get(
"https://api.public.bitpanda.com/v1/earn/configs",
headers={"x-api-key": os.environ["BITPANDA_API_KEY"]},
)
for config in r.json()["configs"]:
print(config["asset"], config["apy"])Node's native fetch ignores proxy env vars; hand it undici's ProxyAgent instead.
import { ProxyAgent } from 'undici';
const dispatcher = new ProxyAgent(process.env.HTTPS_PROXY);
const res = await fetch('https://api.public.bitpanda.com/v1/portfolio-history', {
dispatcher,
headers: { 'x-api-key': process.env.BITPANDA_API_KEY },
});
const history = await res.json();
console.log(history); // valued in EUR by defaultThe allow list is set while the key is being created, so a little checklist discipline up front is all the maintenance this ever needs.
# creating the key: Account settings -> API Keys -> New API key
# scopes: tick only what the workload needs (least privilege)
# expiry: keys live at most one year, calendar the rotation
# allow list: paste BOTH fixed IPv4 addresses, then generate
# the full key is shown once, store it in a secret manager
# Fusion keys work the same way:
# Profile -> API Keys, "whitelist trusted IP addresses only"
# still calling api.bitpanda.com/v1? it turns off after
# 31 January 2027; pin egress now, migrate endpoints at willFlip the toggle with a straight face
Your account ships with a pair of static EU IPv4 addresses. Put both into the IP allow list when each key is created, and put the same pair into every key that follows. Because both addresses are listed, a proxy failover never orphans the key, and the yearly replacement is a paste of two addresses that have not moved.
Which traffic is covered? Your outbound authenticated REST calls, to api.public.bitpanda.com for portfolio, quote and Earn endpoints, plus desk trading on Fusion and agent traffic to mcp.public.bitpanda.com. The legacy api.bitpanda.com/v1 host keeps answering only until 31 January 2027; route it through the pair as well while you migrate, so the rewrite never changes your source address. Nothing flows inbound: today's Bitpanda APIs are request/response with no published webhook source list, so there is no third-party IP set to mirror on your firewall.
📖 Complete Documentation: For detailed examples, error handling, and advanced configurations, see the Python guide, the Node.js guide, or all guides.
Bitpanda was founded in Vienna in 2014 and became Austria's first unicorn, holding MiCA licences covering both Austria and Germany. None of that changes where your requests leave from: that part is your call.
An EU-regulated venue deserves an EU-regulated path. Your outbound hop stays in EU data centres, keeping one simple residency story for the order and portfolio data riding in your API calls, whatever GDPR paper you file.
Bitpanda already built the locks: scoped permissions, a one-year maximum lifetime, 2FA at creation, a key displayed exactly once. The IP allow list is the one that still matters after a key leaks, and TLS passthrough keeps your x-api-key sealed the whole way there.
Two single public IPv4 addresses, exactly the artifact the toggle wants. Paste them once per key and the recommendation is satisfied for good.
Keys come and go on their one-year clock. The addresses you paste into each new key never change, so rotation stops being an egress project.
TLS passthrough keeps your x-api-key header and order payloads encrypted through the proxy hop, all the way to Bitpanda.
Both addresses sit in the allow list, so a proxy failover is a non-event: the backup address was already trusted before it was ever needed.
Containers reschedule, serverless functions cold-start, CI runners vanish. Whatever hosts your workloads this quarter, the pair Bitpanda knows you by stays constant.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
One environment variable points your Bitpanda traffic at two fixed EU addresses the key already trusts, from the first quote to the yearly rotation.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
No, and that is exactly the trap. The IP allow list is optional but recommended, and the security best practices tell you to restrict API access to your server's specific static IP address whenever possible. On egress that rotates, enabling it breaks the next deploy, so teams leave keys unrestricted and the recommendation quietly dies. A fixed pair makes it something you can simply follow.
During key creation. On the platform go to Account settings, then API Keys, then New API key: toggle the IP allow list and paste both fixed IPv4 addresses before you generate the key. On Fusion the same step lives under Profile, then API Keys, described as whitelisting trusted IP addresses only. Confirm with 2FA and store the key safely; it is displayed exactly once.
Yes. Route the legacy host through the pair today, then move call sites over to api.public.bitpanda.com whenever you are ready. Bitpanda decommissions the legacy API after 31 January 2027, and because your source addresses never change during the rewrite, the allow list is the one part of the migration you can finish first.
Tell us what runs your Bitpanda integration today, and we will map the fixed pair onto it.
Contact Our Founders →