API v2: chave, lista de IP confiáveis, HMAC

Modelo de acesso. Todas as requisições à API v2 são executadas em nome de um par de chaves
publicKey/secretKey.
As chaves são criadas na conta pessoal ou via v1 (/api/v1/users/generate-api-key).

Restrição por IP. Ao criar uma chave, especifique os endereços confiáveis em
whiteListIp.
Requisições fora dessa lista são rejeitadas.

Assinatura de cada requisição. Os cabeçalhos devem incluir:

X-Api-Public-Key — seu publicKey

X-Api-Timestamp — string de timestamp (por exemplo, milissegundos epoch)

X-Api-Signature — assinatura HMAC-SHA256 em Base64

Fórmula da assinatura

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

Onde body — JSON sem espaços extras (use serialização compacta).

Exemplo (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/sessão

Dois caminhos de acesso. É possível a verificação manual através do suporte — solicitar acesso permanente (fornecer projeto, volumes, whitelist IP, ID de parceiro).

Autenticação JWT. Obtenha tokens através de
POST /api/v1/users/local/authenticate (campos:
email, password, browserFingerprint).
Na resposta, o servidor define cookies:
session_id, access_token, refresh_token.

Exemplo de requisição (corpo JSON)

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

Os tokens/cookies são usados para chamar métodos protegidos de v1 e para gerar chaves da API v2 via
/api/v1/users/generate-api-key.

Recomendações para armazenamento de chaves e tokens

Não armazenar no código/repositório. Use variáveis de ambiente ou gerenciadores de segredos (Vault, AWS Secrets Manager, GCP Secret Manager, etc.).

Separar ambientes. Chaves separadas para dev/stage/prod. Para dev — limitado
whiteListIp e permissões reduzidas.

Minimizar a superfície de ataque. Execute requisições à v2 apenas no backend, nunca gere chaves e HMAC no frontend.

Rotação regular. Reemita chaves periodicamente, exclua as não utilizadas
(/api/v1/users/list-api-key, /api/v1/users/delete-api-key).

Registro sem segredos. Não registre
secretKey, tokens ou cabeçalhos completos de autorização; registre apenas hashes/IDs e códigos de resposta.

TLS em todos os lugares. Use apenas
https. Rejeite redirecionamentos para esquemas inseguros.

Cookies seguros. Para v1, use as flags
HttpOnly, Secure; armazene tokens apenas em contêineres de sessão protegidos.

Tratamento de erros e novas tentativas. Em 429/5xx — use backoff exponencial. Verifique o corpo da resposta e a validade dos parâmetros obrigatórios.

Acesso pelo princípio do menor privilégio. Forneça chaves e tokens aos serviços estritamente onde forem necessários; não os compartilhe entre equipes/microserviços sem necessidade.