API v2: clave, lista blanca de IP, HMAC

Modelo de acceso. Todas las solicitudes a la API v2 se realizan en nombre de un par de claves
publicKey/secretKey.
Las claves se crean en la cuenta personal o mediante v1 (/api/v1/users/generate-api-key).

Restricción por IP. Al crear una clave, especifique las direcciones de confianza en
whiteListIp.
Las solicitudes fuera de esta lista se rechazan.

Firma de cada solicitud. Los encabezados deben incluir:

X-Api-Public-Key — su publicKey

X-Api-Timestamp — cadena de marca de tiempo (por ejemplo, milisegundos epoch)

X-Api-Signature — firma HMAC-SHA256 en Base64

Fórmula de la firma

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

Donde body — JSON sin espacios adicionales (utilice serialización compacta).

Ejemplo (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/sesión

Dos caminos de acceso. Es posible la verificación manual a través del soporte — solicitar acceso permanente (proporcionar proyecto, volúmenes, whitelist IP, ID de socio).

Autenticación JWT. Obtenga tokens mediante
POST /api/v1/users/local/authenticate (campos:
email, password, browserFingerprint).
En la respuesta, el servidor establece cookies:
session_id, access_token, refresh_token.

Ejemplo de solicitud (cuerpo JSON)

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

Los tokens/cookies se utilizan para llamar a métodos protegidos de v1 y para generar claves de API v2 mediante
/api/v1/users/generate-api-key.

Recomendaciones para el almacenamiento de claves y tokens

No almacenar en el código/repositorio. Use variables de entorno o gestores de secretos (Vault, AWS Secrets Manager, GCP Secret Manager, etc.).

Separar entornos. Claves separadas para dev/stage/prod. Para dev — limitado
whiteListIp y permisos reducidos.

Minimizar la superficie de ataque. Ejecute solicitudes a v2 solo desde el backend, nunca genere claves y HMAC en el frontend.

Rotación regular. Reemita claves periódicamente, elimine las no utilizadas
(/api/v1/users/list-api-key, /api/v1/users/delete-api-key).

Registro sin secretos. No registre
secretKey, tokens ni encabezados completos de autorización; registre solo hashes/ID y códigos de respuesta.

TLS en todas partes. Use solo
https. Rechace redirecciones a esquemas no seguros.

Cookies seguras. Para v1 use las banderas
HttpOnly, Secure; almacene los tokens solo en contenedores de sesión protegidos.

Manejo de errores y reintentos. En 429/5xx — use backoff exponencial. Verifique el cuerpo de la respuesta y la validez de los parámetros obligatorios.

Acceso con el principio de privilegios mínimos. Proporcione claves y tokens a los servicios estrictamente donde se necesiten; no los comparta entre equipos/microservicios sin necesidad.