Skip to main content

​
URL base

​
Autenticação

Toda requisição à API deve incluir sua chave de API no header api-key:
Sua chave de API está disponível no dashboard da Noxpay em Configurações → Chaves de API. A chave identifica sua conta, e sua conta delimita toda requisição: leituras são filtradas para suas próprias transações e escritas são registradas na sua conta. Não há como alcançar dados de outra conta.
Nunca exponha sua chave de API em código client-side. Todas as requisições à API da Noxpay devem partir do seu backend.
A chave de API autentica sua conta — ela não restringe quais operações podem ser executadas. Não existe chave de API somente leitura: qualquer chave válida pode criar um checkout ou aceitar uma conversão. Trate toda chave como acesso total e faça o controle de permissões na sua própria camada.
Toda resposta autenticada carrega o header X-API-Version com a tag do build atual.

​
Formato da requisição

Todo endpoint POST rejeita campos desconhecidos. Uma chave extra ou com erro de digitação no corpo retorna 400, em vez de ser ignorada silenciosamente — então uma requisição que funcionava não passa a se comportar de outro jeito depois que um campo é renomeado. Query params se comportam ao contrário: um parâmetro não reconhecido em um GET é ignorado, e um valor inválido para um parâmetro conhecido em geral é descartado, não rejeitado. Veja as páginas de cada endpoint para os detalhes.

​
Códigos de status

​
Responses de erro

O formato do corpo de erro não é uniforme, então ramifique pelo status HTTP, não pelo corpo. Existem três formas:
  1. Um objeto JSON, com o tipo correto — os endpoints de conversão:
    Em uma recusa, POST /v2/rfq/accept devolve o objeto de resposta completo, carregando state e reason.
  2. Um objeto JSON enviado com Content-Type: text/plain — POST /v2/crossramp_checkout. O corpo é JSON apesar do header, então interprete o corpo e ignore o content type.
  3. Nenhum corpo — as rotas GET de registro único e de lista escrevem apenas a linha de status em 401, 404 e 500.
Trate o corpo de erro como enriquecimento opcional. Um cliente robusto decide o que aconteceu pelo código de status e depois lê o corpo, se houver.