API legada

Depreciada

Esta API existe para quem já tem integração com a plataforma anterior migrar para a Auryon trocando só o endereço e as chaves. Ela reproduz as rotas, os campos e os erros da API antiga.

Integrações novas devem usar a API v1. ⚠️ Esta camada será desligada em 31 de dezembro de 2026. Depois dessa data, só a API v1 responde.

O que muda na migração está no guia de migração. Leia antes de apontar a integração para cá.

Especificação OpenAPI 3.1: openapi-legacy.json, gerada a partir do código.

---

Base e autenticação

URL base	https://api.auryon369.com.br/api/v1
Autenticação	cabeçalhos x-public-key e x-secret-key, como antes

Gere as credenciais no painel da Auryon em Integrações → API. As permissões são as mesmas de antes: PRODUCER_DATA, PRODUCER_TRANSACTIONS, PRODUCER_WITHDRAWS e PRODUCER_CHECKOUT.

Valores monetários em reais, como número JSON ("amount": 100.50), como na API antiga. A Auryon lê o número exatamente como foi escrito: se vier com mais de duas casas, arredonda para o centavo mais próximo (meio para cima).

---

Endpoints

Método	Rota	Permissão	Situação
GET	/ping	—	✅ igual
GET	/gateway/producer	PRODUCER_DATA	✅ igual
GET	/gateway/producer/balance	PRODUCER_DATA	⚠️ só o saldo em Reais (§3)
GET	/gateway/producer/credentials	qualquer	✅ igual
GET	/gateway/transactions?id=&clientIdentifier=	PRODUCER_TRANSACTIONS	✅ igual
GET	/gateway/subscriptions?…	PRODUCER_TRANSACTIONS	✅ igual
POST	/gateway/producer/refunds	PRODUCER_TRANSACTIONS	✅ reembolso total
POST	/gateway/pix/receive	PRODUCER_TRANSACTIONS	✅ igual
POST	/gateway/boleto/receive	PRODUCER_TRANSACTIONS	✅ igual
POST	/gateway/crypto/receive	PRODUCER_TRANSACTIONS	⚠️ só BDM Digital
POST	/gateway/checkout	PRODUCER_CHECKOUT	✅ é o caminho do cartão
POST	/gateway/card/receive	—	⛔ recusado (§4)
POST	/gateway/card/subscription	—	⛔ recusado (§4)
POST	/gateway/pix/subscription	PRODUCER_TRANSACTIONS	✅ assinatura em PIX (§3)
POST	/gateway/crypto/subscription	PRODUCER_TRANSACTIONS	✅ assinatura em BDM (§3)
POST	/gateway/pix/deposit	—	⛔ não disponível (501)
GET	/utils/exchange-rates?from=&to=&amount=	—	✅ igual

---

Diferenças que você precisa conhecer

Saldo: só Reais

/gateway/producer/balance devolve available, pending e fundLock, apenas da operação em Reais. O formato antigo não tem campo de moeda. Por isso, saldo em dólar ou em BDM não aparece aqui. Para ver todas as moedas, use o painel ou GET /v1/balance.

• available nunca vem negativo. Um valor a compensar (por exemplo, depois de um reembolso de venda já sacada) aparece no painel.
• fundLock soma o valor em reserva e o valor bloqueado.

Cripto: BDM Digital

crypto.currency precisa ser "BDM". Outras moedas são recusadas com 400: a Auryon não cobra numa moeda diferente da que você pediu.

Reembolso

POST /gateway/producer/refunds reembolsa o valor que ainda resta da transação. O status da resposta é o real: COMPLETED quando o valor já voltou ao comprador, PENDING quando está em curso. Um segundo pedido enquanto o primeiro não termina responde 422.

Assinaturas

POST /gateway/pix/subscription e /gateway/crypto/subscription funcionam como antes: a resposta traz a cobrança (o PIX ou o QR) e o objeto subscription. Cada ciclo emite uma cobrança nova e o comprador recebe o aviso para pagá-la.

• A assinatura nasce INACTIVE (a cobrança foi emitida e ainda não foi paga) e vira ACTIVE quando o primeiro pagamento entra.
• ⚠️ periodicityType: DAYS não é suportado. A Auryon cobra por WEEKS, MONTHS ou YEARS.
• ⚠️ firstChargeIn maior que zero não é suportado: a primeira cobrança é emitida agora (é ela que a resposta devolve). Para período de teste, use uma oferta com trial no painel.
• Cartão recorrente (/gateway/card/subscription) continua recusado (§4): crie um checkout de uma oferta recorrente e redirecione o comprador.

Splits

splits[].producerId é o ID da conta Auryon de quem recebe. Cada produtor encontra o próprio ID no painel, em Integrações → API.

• Os IDs da plataforma anterior não valem aqui. Peça o ID novo a cada parceiro.
• A soma dos splits não pode passar do valor líquido da transação (o valor menos a taxa da plataforma). Se passar, a transação inteira é recusada; nenhum split é cortado sem aviso.
• Uma conta inexistente responde 400 com errorCode: GATEWAY_NO_SPLIT_ACCOUNT.

identifier

Continua obrigatório e único. Repetir um identifier com o mesmo pedido devolve a mesma transação, sem criar outra cobrança. É assim que um reenvio por timeout fica seguro.

Repetir um identifier com outro valor ou outra forma de pagamento é recusado com 409 GATEWAY_FAILED_PRECONDITION: é um pedido diferente com um identificador já usado, e devolver a cobrança antiga faria você cobrar o valor errado. Use um identifier novo.

dueDate, shippingFee, extraFee, discount

São aceitos, mas não mudam a cobrança. O valor cobrado é o amount, como a própria doc antiga orientava a calcular. O vencimento do PIX e do boleto segue a configuração da sua conta.

products[]

O nome do primeiro produto aparece nas vendas do painel. Os demais itens não são registrados individualmente.

Checkout (/gateway/checkout)

• offer.price é em reais, como as outras rotas (497.00 = R$ 497,00).
• O produto é criado ou reutilizado pelo product.externalId.
• O produto segue a mesma regra de aprovação dos criados no painel. Se a sua conta aprova produtos automaticamente, ele já nasce aprovado e o link volta na hora. Se não, a resposta é 409 GATEWAY_FAILED_PRECONDITION com details.productId e details.approvalStatus, e nenhuma oferta é criada: chame de novo, com o mesmo externalId, depois que o produto for aprovado. Como o produto é reutilizado pelo externalId, a aprovação acontece uma vez só.
• trackProps segue no link. Os dados de customer não vão para a URL, para não expor dados pessoais em logs e no histórico do navegador.
• settings.askForAddress: true cria o produto como físico, o que faz o checkout pedir o endereço. As cores e os demais itens de settings são configurados no painel.

---

⛔ Cartão pela API

/gateway/card/receive e /gateway/card/subscription respondem sempre:

{
  "statusCode": 400,
  "errorCode": "GATEWAY_FAILED_PRECONDITION",
  "message": "A Auryon não recebe dados de cartão pela API. Crie um checkout com POST /api/v1/gateway/checkout e redirecione o comprador para o checkoutUrl devolvido: o cartão é digitado na página segura da Auryon.",
  "details": { "use": "POST /api/v1/gateway/checkout" }
}

O corpo dessas rotas não é lido. Receber número de cartão e CVV no servidor exigiria a certificação PCI-DSS de nível máximo. Na Auryon o cartão é digitado no checkout e tokenizado no navegador do comprador.

Como vender no cartão: POST /gateway/checkout → redirecione o comprador para o checkoutUrl → receba o TRANSACTION_PAID no webhook.

---

Webhooks (formato antigo)

Pelo callbackUrl

Envie callbackUrl numa rota */receive. A resposta traz o webhookToken, e a Auryon avisa essa URL sobre as transações criadas pela API:

TRANSACTION_CREATED · TRANSACTION_PAID · TRANSACTION_CANCELED · TRANSACTION_REFUNDED · TRANSACTION_CHARGED_BACK

• Use uma URL fixa e identifique o pedido por transaction.identifier. A mesma URL é reutilizada; cada URL diferente conta para o limite de 20 webhooks por conta.
• A URL precisa ser HTTPS.

Pelo painel

Em Integrações → Webhooks, escolha o formato Legado para receber neste formato. Eventos disponíveis: os cinco acima, TRANSFER_CREATED, TRANSFER_COMPLETED, TRANSFER_FAILED e SESSION_ABANDONED.

Validação

Como antes: compare payload.token com o token do webhook antes de processar. Este formato não tem assinatura do conteúdo nem proteção contra reenvio. Por isso está depreciado. O formato V1 assina cada entrega com HMAC (ver a API v1).

Rotação do token: no formato legado a troca é imediata. O corpo leva um token só, então, a partir da rotação, só o novo é enviado; não há a janela de 24 horas do formato V1. Atualize o seu servidor logo depois de rotacionar.

Payload

{
  "event": "TRANSACTION_PAID",
  "token": "…",
  "offerCode": "ABC1234",
  "checkoutUrl": "",
  "client": {
    "id": "txn_…",
    "name": "João da Silva",
    "email": "joao@gmail.com",
    "phone": null,
    "cpf": null,
    "cnpj": null,
    "address": null
  },
  "transaction": {
    "id": "txn_…",
    "identifier": "pedido-123",
    "status": "COMPLETED",
    "paymentMethod": "PIX",
    "originalAmount": 100.50,
    "amount": 100.50,
    "originalCurrency": "BRL",
    "currency": "BRL",
    "exchangeRate": 1,
    "installments": 1,
    "createdAt": "2026-09-17T12:00:00.000Z",
    "payedAt": "2026-09-17T12:01:00.000Z"
  },
  "subscription": null,
  "orderItems": [
    { "id": "txn_…-1", "price": 100.50, "product": { "id": null, "name": "Curso", "externalId": null } }
  ],
  "trackProps": {}
}

⚠️ cpf, cnpj, phone e address do comprador vêm sempre null, e payoutAccount dos eventos de saque também. Os campos existem para o seu parser não quebrar, mas a Auryon não envia dados pessoais sensíveis para fora da plataforma.

Status: COMPLETED (pago, inclusive com reembolso parcial) · PENDING · FAILED (recusado ou expirado) · REFUNDED · CHARGED_BACK.

Responda 2xx. Falhas são retentadas (até 6 tentativas em cerca de 30 horas). As regras de saúde, desativação e reenvio são as mesmas do formato V1 (API v1).

TRANSACTION_CANCELED sai quando a cobrança é encerrada sem pagamento: venceu, ou o comprador desistiu dela (por exemplo, recusou um upsell que estava aguardando pagamento).

---

Erros

{ "statusCode": 400, "errorCode": "GATEWAY_INVALID_DATA", "message": "…", "details": [{ "path": "amount", "error": { "message": "…" } }] }

errorCode	Quando
GATEWAY_NO_CREDENTIALS	cabeçalhos de credencial ausentes
GATEWAY_INVALID_CREDENTIALS	credencial inválida, revogada ou expirada
GATEWAY_PERMISSION_DENIED	a credencial não tem a permissão
GATEWAY_INVALID_DATA	corpo inválido (veja details), inclusive JSON malformado (400, "JSON inválido.")
GATEWAY_NO_BODY	corpo ausente
GATEWAY_INVALID_ARGUMENT	pedido válido mas não atendível (ex.: reembolso já em curso)
GATEWAY_NO_SPLIT_ACCOUNT	producerId de split inexistente
GATEWAY_TRANSACTION_NOT_FOUND	transação inexistente ou de outra conta
GATEWAY_FAILED_PRECONDITION	operação recusada: cartão pela API (400); identifier já usado com outro valor ou meio, produto do checkout ainda não aprovado, conta que não pode vender (409)
GATEWAY_UNIMPLEMENTED	rota sem equivalente na Auryon
GATEWAY_UNAVAILABLE	serviço temporariamente indisponível, inclusive manutenção programada (503, com Retry-After)
GATEWAY_INTERNAL_SERVER_ERROR	falha nossa

Limite: 100 requisições por minuto por credencial, somando todas as rotas (as da v1 inclusive); a consulta de transação e de assinatura tem um teto próprio de 30 por minuto. Acima do limite, a resposta é 429 no formato antigo:

{ "success": false, "error": { "code": "TOO_MANY_REQUESTS", "message": "Tentativa de polling bloqueada. Receba atualizações via webhook." } }