> ## Documentation Index > Fetch the complete documentation index at: https://docs.thedecard.com/llms.txt > Use this file to discover all available pages before exploring further. # IP Whitelisting > This is the network configuration page of Integration Resources. It picks up the "provide your IP whitelist" step from First Steps and sets out which egress IPs a partner has to register with DCS, what each one is used for, and how sandbox is kept apart from production. Request headers and the signing algorithm are covered in the Authentication Guide, and the secure retrieval flow for credentials is covered in First Steps. **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](#4-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](../getting-started/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](./webhook-websocket)). 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)**: ```text theme={null} # API call egress IP Sandbox egress IP: Production egress IP: # One-time production credential retrieval (production only) Secure email address: # receives the credential retrieval email Credential retrieval request 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. *** ## Next steps / Related * Request headers and the signing algorithm: [Authentication Guide](./overview) * Receiving and securely retrieving credentials: [First Steps](../getting-started/first-steps) * Integration requirements for event push: [Webhook + WebSocket Notifications](./webhook-websocket)