API REST

Autenticação, endpoints, objetos e erros. Com exemplos que rodam copiados e colados.

A API do HAS dá ao seu time acesso programático às vulnerabilidades, aos pentests e ao painel da sua empresa. Use para levar achados ao seu SIEM, abrir tickets no seu backlog ou fechar o ciclo de correção pelo seu próprio fluxo.

https://api.hackersec.com/v1

Autenticação

Toda requisição leva sua chave secreta no header Authorization:

curl https://api.hackersec.com/v1/dashboard \
  -H "Authorization: Bearer hackersec_has_sk_..."

Criando a chave

• Em Configurações → Integrações → API. O master da empresa cria e revoga as chaves.
• O valor aparece uma única vez, no momento da criação. Guarde no cofre de segredos do seu time. Se perder, revogue e crie outra.
• Cada chave vale para uma empresa.
• A tela mostra o último uso de cada chave. Chave parada há meses é chave para revogar.

Escopos

O escopo é escolhido na criação e vale por toda a vida da chave. Para integração que só consulta, como dashboard, SIEM ou relatório, use read.

Convenções

• JSON na entrada e na saída. Datas em ISO-8601 UTC (2026-08-24T14:02:11Z).
• Todo objeto traz id e object.
• Toda resposta traz o header Request-Id. Cite-o ao falar com o suporte.
• Campo desconhecido devolve 400, com o nome do campo em param.

Listas e paginação

Toda listagem devolve o mesmo envelope, do mais recente para o mais antigo:

{
  "object": "list",
  "data": [ ... ],
  "has_more": true,
  "next_cursor": "5214"
}

Use limit (padrão 100, máximo 200) e passe o next_cursor em starting_after para a página seguinte. Enquanto has_more for true, ainda há resultado.

Endpoints

Listar vulnerabilidades

Filtros: severity, status, test, limit, starting_after. Os valores de severity e status são os mesmos que a resposta devolve.

curl "https://api.hackersec.com/v1/vulnerabilities?severity=critical&status=reported" \
  -H "Authorization: Bearer $HACKERSEC_KEY"

Mudar o status

Valores aceitos: reported, in_correction, ignored, mitigated, retest.

curl -X POST https://api.hackersec.com/v1/vulnerabilities/16590818124833/status \
  -H "Authorization: Bearer $HACKERSEC_KEY" \
  -H "Content-Type: application/json" \
  -d '{"status":"in_correction"}'

ignored e mitigated exigem justification, de 50 a 2800 caracteres. São declarações suas: uma aceita o risco como está, a outra afirma que existe controle compensatório. O texto sai no relatório em PDF ao lado da vulnerabilidade, então escreva a decisão real.

curl -X POST https://api.hackersec.com/v1/vulnerabilities/16590818124833/status \
  -H "Authorization: Bearer $HACKERSEC_KEY" \
  -H "Content-Type: application/json" \
  -d '{"status":"ignored","justification":"Endpoint acessível apenas pela VPN corporativa, com MFA obrigatório. Risco aceito pelo comitê de segurança em 12/08."}'

Pedir reteste

curl -X POST https://api.hackersec.com/v1/vulnerabilities/16590818124833/retest \
  -H "Authorization: Bearer $HACKERSEC_KEY" \
  -H "Content-Type: application/json" \
  -d '{"context":"Parâmetro passou a usar consulta parametrizada. Deploy em produção hoje."}'

O context é opcional e ajuda: ele diz a quem vai retestar o que mudou. Com um reteste já pendente para aquela vulnerabilidade, a chamada devolve 409, sinalizando que o pedido anterior segue em andamento.

Enviar para a integração

curl -X POST https://api.hackersec.com/v1/vulnerabilities/16590818124833/export \
  -H "Authorization: Bearer $HACKERSEC_KEY" \
  -H "Content-Type: application/json" \
  -d '{"integration":"jira"}'

Omita integration ou use "all" para disparar todas as integrações ativas. Exige integração configurada na empresa e chave de um master.

O objeto Vulnerability

Buscando uma vulnerabilidade específica, vêm também description, remediation, references, evidence (as provas de conceito) e comments.

O objeto Test

Erros

{
  "error": {
    "type": "invalid_request_error",
    "code": "justification_required",
    "message": "A justification of at least 50 characters is required...",
    "param": "justification"
  },
  "request_id": "req_28d675e64f3fe329"
}