API v2: Key, IP whitelist, HMAC

Access model. All requests to API v2 are executed on behalf of a key pair
publicKey/secretKey.
Keys are created in the personal account or via v1 (/api/v1/users/generate-api-key).

IP restriction. When creating a key, specify trusted addresses in
whiteListIp.
Requests from outside this list are rejected.

Request signing. The following headers must be included:

X-Api-Public-Key — your publicKey

X-Api-Timestamp — timestamp string (e.g., epoch milliseconds)

X-Api-Signature — HMAC-SHA256 signature in Base64

Signature formula

StrToSign = timestamp + body + publicKey
Signature = Base64( HMAC_SHA256(StrToSign, secretKey) )

Where body — JSON without extra spaces (use compact serialization).

Example (curl)

curl -X POST "https://quickex.io/api/v2/instruments/public/validate-address" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -H "X-Api-Public-Key: {PUBLIC_KEY}" \
  -H "X-Api-Timestamp: {TIMESTAMP_MS}" \
  -H "X-Api-Signature: {HMAC_BASE64}" \
  -d '{"currencyTitle":"USDT","networkTitle":"TRC20","address":"..."}'

API v1: JWT/session

Two access paths. Manual verification through support is possible — request permanent access (provide project, volumes, whitelist IP, partner ID).

JWT authentication. Obtain tokens via
POST /api/v1/users/local/authenticate (fields:
email, password, browserFingerprint).
In the response, the server sets cookies:
session_id, access_token, refresh_token.

Request example (JSON body)

{
  "email": "user@example.com",
  "password": "yourpassword",
  "browserFingerprint": "unique-browser-id"
}

Tokens/cookies are used to call protected v1 methods and to generate v2 API keys via
/api/v1/users/generate-api-key.

Recommendations for storing keys and tokens

Do not store in code/repository. Use environment variables or secret managers (Vault, AWS Secrets Manager, GCP Secret Manager, etc.).

Separate environments. Use separate keys for dev/stage/prod. For dev — limited
whiteListIp and narrowed permissions.

Minimize attack surface. Execute v2 requests only from the backend, never generate keys and HMAC on the frontend.

Regular rotation. Periodically reissue keys, delete unused ones
(/api/v1/users/list-api-key, /api/v1/users/delete-api-key).

Logging without secrets. Do not log
secretKey, tokens, or full authorization headers; log only hashes/IDs and response codes.

TLS everywhere. Use only
https. Reject redirects to insecure schemes.

Secure cookies. For v1, use
HttpOnly, Secure flags; store tokens only in protected session containers.

Error handling and retries. On 429/5xx — use exponential backoff. Check the response body and validity of required parameters.

Principle of least privilege. Provide keys and tokens to services strictly where needed; do not share them across teams/microservices unnecessarily.