Overview (Access Credentials and Developer Configuration)

📄 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), 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.

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:

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).
DCS sends an email to that address containing a temporary secure link, valid for a single extraction.
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):

{
  "code": "SYS_SUCCESS",
  "message": null,
  "messageDetail": null,
  "data": {
    "expireTime": "<EXPIRE_TIME>",
    "extractSecretKey": "<EXTRACT_SECRET_KEY>",
    "extractUrl": "https://<DECARD_DOMAIN>/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.

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:

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).
Send the endpoint to the DCS team: give DCS your callback URL (HTTPS, publicly reachable) and DCS registers it.
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.

Provisioning and go-live sequence

The diagram below shows the joint path from receiving credentials to putting Webhooks into production:

Next steps

Complete credential provisioning and request signing: Integration Resources › Authentication Guide
Register your API whitelist: Integration Resources › IP Whitelisting
Configure event callbacks: Integration Resources › Webhook and WebSocket Real-Time Notifications

​📄 Guide

​Credential provisioning: apiKey / secretKey

​Secure extraction of production credentials

​API whitelisting (IP Whitelisting)

​Webhook setup

​Provisioning and go-live sequence

​Next steps