Skip to main content
POST
Abrir autorização
POST /pix-authorizations Faz parte do recurso Pix Automático — o fluxo completo, os status e o débito de cada ciclo estão lá. Abre a autorização em pending e devolve, em charge, o QR do primeiro pagamento. O mesmo QR faz as duas coisas: cobra firstCharge.amount agora e pede ao pagador a autorização das faturas seguintes, na periodicidade de frequency. Exiba o QR na sua tela e espere o webhook pix_authorization.activated para criar a assinatura.
Envie customer ou customerId — um dos dois, nunca os dois. Os dois juntos, ou nenhum, respondem 400. Um customerId que não é da sua conta responde 404.
A abertura recusada responde 409, não uma cobrança Pix comum. Acontece quando o Pix Automático não está habilitado na sua conta (fale com o suporte), quando falta nome ou documento no cadastro do cliente informado em customerId, ou quando o QR não pôde ser gerado — nesse último caso nada foi cobrado, e você pode tentar de novo.
O primeiro dia autorizado é amanhã. recurrenceBeginningDay sai como o dia seguinte à abertura porque a autorização precisa começar no futuro. Isso não adia cobrança nenhuma: o primeiro pagamento sai agora, pelo QR, e o dia de cada débito seguinte é o vencimento da fatura da assinatura.
Com customer no corpo, customerId vem nulo nesta resposta. O cliente é criado junto com o primeiro pagamento e vinculado logo em seguida — o GET e os webhooks já o trazem.
additionalInfo acompanha o primeiro pagamento, não a autorização. Ele é gravado na transação de charge.transactionId; a autorização não o devolve.

Exemplo

Resposta 201

Authorizations

x-api-key
string
header
required

API Key da Credential (gerada no Backoffice)

Body

application/json
frequency
enum<string>
required

Com que frequência o pagador será debitado. weekly, monthly, quarterly, semiannual ou annual — outras cadências seguem em Pix comum, pago manualmente a cada ciclo.

Available options:
weekly,
monthly,
quarterly,
semiannual,
annual
firstCharge
object
required

A cobrança que o QR liquida agora — obrigatória nesta versão.

customerId
string

Cliente já cadastrado (cust_). Exclusivo com customer.

customer
object

Dados do pagador. Nome e documento são exigidos pelo arranjo para registrar a autorização junto ao banco dele — sem eles não há autorização a propor.

endDate
string<date-time>

Até quando a autorização vale (ISO 8601 com fuso). Omitida, ela vale até ser cancelada.

additionalInfo
object

Dados seus, gravados na transação do primeiro pagamento.

Response

Autorização aberta, com o QR da primeira cobrança

id
string

ID da autorização (pxa_).

customerId
string | null

Cliente pagador (cust_). Na resposta da abertura vem nulo quando o pagador foi enviado em customer: o vínculo é preenchido logo depois, e o GET já o traz.

subscriptionId
string | null

Assinatura que usa esta autorização como forma de pagamento. Nulo até a assinatura ser criada — e para sempre numa autorização que nunca virou assinatura.

status
enum<string>

Situação da autorização: pending, active, canceled ou expired. canceled e expired são finais.

Available options:
pending,
active,
canceled,
expired
frequency
enum<string>

Periodicidade que o pagador autorizou: weekly, monthly, quarterly, semiannual ou annual. Precisa ser a mesma da assinatura.

Available options:
weekly,
monthly,
quarterly,
semiannual,
annual
recurrenceBeginningDay
string

Primeiro dia em que o débito pode acontecer (YYYY-MM-DD), no calendário da sua conta. Na abertura pela API é o dia seguinte — o primeiro pagamento sai na hora, pelo QR.

endDay
string | null

Último dia de validade (YYYY-MM-DD), resolvido a partir do endDate enviado. Nulo quando a autorização vale até ser encerrada.

createdAt
string

Criação, ISO 8601.

updatedAt
string

Última alteração, ISO 8601.

charge
object

O primeiro pagamento, que o QR cobra agora. Só vem na resposta da abertura.