> ## 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. # Overview (Access Credentials and Developer Configuration) > Covers the three developer configurations you complete before integration: apiKey / secretKey credential provisioning (including secure extraction in production), API IP whitelisting, and Webhook setup. ## 📄 Guide Before you start integrating, you need a set of access credentials from DCS, plus registered API whitelisting and callback (Webhook) settings. As a licensed issuer with its own BINs, DCS handles credential provisioning, IP whitelist registration, and Webhook setup jointly with your team, so that every production key is delivered securely. The three steps are described below. ## Credential provisioning: apiKey / secretKey DCS provisions one set of access credentials per Enterprise (the entity you integrate under). These credentials gate every API call: | Field | Description | | ----------- | ------------------------------------------------------------------------------------------- | | `apiKey` | The key used to call open-api; identifies you and lets DCS trace the origin of each request | | `secretKey` | The key used to sign requests (HmacSHA256). Store it securely and never disclose it | The DCS team hands the credentials over to you: * **Sandbox**: contact the DCS team directly for your `apiKey` / `secretKey`. * **Production**: credentials are delivered through a secure email plus a one-time extraction link (see [Secure extraction of production credentials](#secure-extraction-of-production-credentials)), so that they are never exposed to a third party in transit. > For how the credentials feed into request signing (`X-DAPI-API-KEY` / `X-DAPI-SIGN` / `X-DAPI-TIMESTAMP` / `X-DAPI-NONCE`, and the HmacSHA256 signing rules), see [Integration Resources › Authentication Guide](../integration-resources/overview). ### Secure extraction of production credentials To keep the production `apiKey` / `secretKey` from reaching any third party, production credentials are extracted once, through the following flow: 1. Give the DCS team a **secure email address** (which receives the extraction instructions) and the **IP address that will perform the extraction** (added to the extraction whitelist). 2. DCS sends an email to that address containing a **temporary secure link, valid for a single extraction**. 3. Concatenate `extractUrl` with `extractSecretKey` and run it on the designated machine to retrieve the `apiKey` / `secretKey`. Fields contained in the email: | Field | Type | Description | | ------------------ | ------ | ----------------------------------------------- | | `expireTime` | string | Validity period of the extraction security code | | `extractSecretKey` | string | Extraction security code | | `extractUrl` | string | Extraction URL | | `howToUse` | string | How to use the link | | `notes` | string | Reminder that the link can only be used once | Successful response from the extraction flow (keys, URL, and timestamp below are placeholders): ```json theme={null} { "code": "SYS_SUCCESS", "message": null, "messageDetail": null, "data": { "expireTime": "", "extractSecretKey": "", "extractUrl": "https:///internal/open-api/v1/secret-extract/", "howToUse": "Please concatenate the url with the secret-key and execute it on the specified machine.", "notes": "This link is only valid for one AKSK extraction. If the content is not properly accessed, the AKSK may have been compromised, please contact us promptly." } } ``` > **Response envelope**: every endpoint returns `{code, message, messageDetail, data}`. The success code literal is `SYS_SUCCESS`; there is no `success` boolean field. > **Security note**: the temporary link **can only be used once**. If the extraction does not succeed, assume the keys may already have been exposed within the validity window; contact your DCS business contact immediately and have a new email issued. ## API whitelisting (IP Whitelisting) DCS enforces **API whitelisting**: only registered network egress addresses may call open-api. When you request credentials, also send the DCS team your **network egress addresses**: * Sandbox egress IP * Production egress IP > For more on IP whitelisting (multiple addresses, change procedure, and so on), see [Integration Resources › IP Whitelisting](../integration-resources/ip-whitelisting). ## Webhook setup DCS pushes events such as KYC status changes, asset movements, card transactions, and order status through Webhooks. You implement the receiver, then the DCS team registers it: 1. **Implement the receiver**: expose a POST endpoint that accepts `application/json` and returns `200 OK` within 2 seconds (any other status code triggers a retry). 2. **Send the endpoint to the DCS team**: give DCS your callback URL (HTTPS, publicly reachable) and DCS registers it. 3. **Verify and go live**: go live once verification in UAT passes. DCS signs each Webhook by computing `X-Signature` over the message body with HmacSHA256 using your `secretKey`; you verify it. For the full event format, signature verification, and receiver examples, see [Integration Resources › Webhook and WebSocket Real-Time Notifications](../integration-resources/webhook-websocket). ## Provisioning and go-live sequence The diagram below shows the joint path from receiving credentials to putting Webhooks into production: Credential provisioning and go-live sequence Credential provisioning and go-live sequence ## Next steps * Complete credential provisioning and request signing: [Integration Resources › Authentication Guide](../integration-resources/overview) * Register your API whitelist: [Integration Resources › IP Whitelisting](../integration-resources/ip-whitelisting) * Configure event callbacks: [Integration Resources › Webhook and WebSocket Real-Time Notifications](../integration-resources/webhook-websocket)