IP Whitelisting - DCS Technical Documentation

Direction of the whitelist: in the DeCard-Managed model the whitelist is supplied by the partner and contains the partner’s own network egress addresses, which DCS then allows to call its APIs. This page lists no DCS-owned IPs.

1. Why IP whitelisting is required

DCS enforces IP whitelisting on API calls: only requests coming from a network egress address that the partner has registered in advance are let through. This is a network-level admission check on top of API Key / Secret Key signature authentication, and it confines the set of possible callers to trusted network ranges. Register your network egress IP with DCS before you call any API. If it is missing or incorrect, the request is rejected before it reaches any business logic (see Troubleshooting).

2. The two kinds of IP to register

In the DeCard-Managed model (dedicated-account model), authorization decisions are made inside DCS. There is no leg on which DCS forwards an authorization back to the partner, so there is no whitelist for an authorization-forwarding direction. What you do need to register with DCS are the following two egress IPs, which serve different purposes:

Purpose	Supplied by	Direction	Description
API call whitelist	Partner	Partner → DCS	The network egress address from which you call the DeCard-Managed APIs. Only source IPs on this list can call the APIs successfully.
Production credential retrieval IP	Partner	Partner → DCS	The IP of the request that performs the one-time retrieval of the API Key / Secret Key in production. This IP is added to the “credential retrieval” whitelist, and the temporary link sent by email can only be used from that machine.

The two addresses serve different purposes, so register them separately. The egress IP used for day-to-day API calls and the request IP used for the one-time production credential retrieval do not have to be the same; state what each address is for when you submit them to DCS. The full retrieval flow is described in the “Secure Retrieval of Production Credentials” section of First Steps.

About the Webhook direction

DCS pushes events to you over Webhook: KYC status, asset movements, card transactions, order status and so on. The integration requirement for Webhook is that you expose an HTTPS callback URL reachable from the public internet and verify the authenticity of every call with a digital signature (see Webhook + WebSocket Notifications).

If your Webhook receiver needs IP-level inbound restrictions, contact the DCS team to confirm its outbound IP ranges. This page lists no DCS IPs.

3. Environment separation (sandbox and production, never mixed)

DCS keeps the sandbox and production environments apart, and their whitelists are independent of each other. Provide the network egress addresses for the two environments separately and never mix them:

Environment	API call whitelist	Production credential retrieval IP	How to submit
Sandbox	Provide your sandbox egress IP	Not applicable (sandbox credentials come directly from the DCS team)	Contact the DCS team
Production	Provide your production egress IP	Provide the request IP for the one-time production credential retrieval	Submit through your commercial contact or the DCS team

What to submit (placeholder example, replace with your own details):

# API call egress IP
Sandbox egress IP:                 <your-sandbox-egress-ip>
Production egress IP:              <your-production-egress-ip>

# One-time production credential retrieval (production only)
Secure email address:              <your-secure-email>   # receives the credential retrieval email
Credential retrieval request IP:   <your-extract-ip>     # IP of the machine on the "credential retrieval" whitelist

How to submit: for the sandbox environment, contact the DCS team directly; for production, submit through your commercial contact or the DCS team and state the purpose of each IP.

4. Troubleshooting

Common symptoms when a whitelist entry is missing or wrong, and how to work through them:

Symptom	Likely cause	What to do
API request rejected (a network-layer rejection, separate from authentication)	The egress IP actually used is not on the API call whitelist (machines scaled out, egress gateway changed, NAT egress IP drift)	Confirm your current real egress IP and submit it to DCS so it can be added to the whitelist
Connection blocked by a firewall or timing out	Your own firewall restricts outbound connections to DCS	Allow outbound access to DCS on your side
The production credential retrieval link fails to run	The IP of the machine running it does not match the registered “credential retrieval request IP”, or the link has already been used (it is valid once only)	Run it on the machine you registered; if the link is spent, arrange a new email through your commercial contact
Works in sandbox but rejected in production	Sandbox and production whitelists were not configured separately (the same set was reused)	Register a production egress IP of its own

When tracking down your egress IP, use the public egress IP of the machine or gateway that actually sends the request, not a private network address.

Request headers and the signing algorithm: Authentication Guide
Receiving and securely retrieving credentials: First Steps
Integration requirements for event push: Webhook + WebSocket Notifications

​1. Why IP whitelisting is required

​2. The two kinds of IP to register

​About the Webhook direction

​3. Environment separation (sandbox and production, never mixed)

​4. Troubleshooting

​Next steps / Related

1. Why IP whitelisting is required

2. The two kinds of IP to register

About the Webhook direction

3. Environment separation (sandbox and production, never mixed)

4. Troubleshooting

Next steps / Related