Changelog

Este documento registra todas as alterações notáveis na API CorpX.

v2.53.0 (2026-08-07) - `maxLookupRatio` sai, e os limites por janela passam a valer sempre

O limite maxLookupRatio foi removido. Ele permitia ratio × transferências concluídas nas últimas 24h consultas de chave. Era o mesmo cálculo do maxUsageRatio da janela de 24h, com resolução pior: uma janela só, sem piso de amostra próprio, dependendo de um piso global de 50 consultas para não travar conta sem transferência. As janelas fazem o mesmo em doze faixas, de 5 minutos a 30 dias.
O campo continua sendo aceito e é ignorado. Policy que ainda o traga no corpo não passa a dar erro; o número simplesmente deixa de decidir. O motivo de negação ratio não aparece mais nas mensagens de 429, e a nota (bootstrap floor of 50 lookups/24h applied) também some.
Os limites por janela agora valem sempre. Antes eles só existiam onde alguém os tivesse escrito na policy. Agora, faixa sem números declarados herda a linha de base da frota: maxUsageRatio 2.2 e maxFailureRatio 0.3 em todas as janelas, com piso de amostra de 20 até 30 minutos, 50 de 1h a 12h e 500 por dia de janela a partir de 24h. Esses valores saíram da medição de 14 dias de tráfego real e não barravam nenhuma conta no histórico.
O que você precisa fazer. Provavelmente nada. Se a policy da sua conta declarava um maxLookupRatio mais apertado que 2.2 consultas por transferência, o teto efetivo afrouxa; se declarava um mais folgado, a janela de 24h passa a decidir. Os tetos absolutos (maxLookupsPerDay, maxLookupsPerMinute, maxNotFoundPer5min) não mudaram. Detalhes em Políticas.

v2.51.0 (2026-08-07) - Limites de consulta de chave por janela de tempo

Novos tetos de taxa por janela de tempo na policy dictLookup. Além dos quatro limites que já existiam, cada janela (5m, 15m, 30m, 1h, 3h, 6h, 12h, 24h, 3d, 7d, 14d, 30d) pode limitar duas taxas: consultas por PIX Out concluído (maxUsageRatio) e fração de consultas que não resolvem chave (maxFailureRatio). Detalhes e exemplos em Políticas.
Nada muda para quem não configurar. As janelas não vêm ligadas: elas só valem na conta ou no tenant em que forem configuradas, e o comportamento de quem não mexer em nada continua idêntico.
O errorCode continua dict_lookup_limit_exceeded. O que muda é a mensagem, que passa a dizer qual janela estourou, o que foi medido e qual era o teto — por exemplo, 120 lookups for 10 successful transfers (12.0 per transfer); max 6.0. Quem trata o código não precisa mudar nada; quem exibe a mensagem ao usuário final passa a ter um texto mais útil.
Quando mais de uma janela estoura, a resposta cita a mais curta, que é a causa imediata e a primeira a liberar.
Cada janela tem um piso de amostra (minLookups). Abaixo dele nenhuma das duas taxas recusa, para que uma conta nova, com pouquíssimas consultas, não seja bloqueada por uma taxa calculada sobre três chamadas.

v2.50.0 (2026-08-07) - O titular volta para o seu app ao fim do onboarding e da portabilidade

Novo campo opcional callbackUri em POST /v1/accreditations/pf e POST /v1/accreditations/pj. Ao terminar a etapa dele — captura facial, aceite BYO ou autorização de portabilidade — o titular é levado de volta para o seu app ou site, em vez de parar numa página de conclusão nossa. O desfecho vai na própria URI, em outcome, junto de accreditationId, do personId de quem concluiu e, quando o credenciamento tem mais de uma pessoa, de remainingPeople. Guia completo em Retorno ao seu app.
A URI precisa ser cadastrada antes do primeiro uso. Fale com o suporte da CorpX informando exatamente a URI que você vai usar. São aceitas https:// e o esquema do seu aplicativo (deeplink); a comparação é exata, sem wildcard e sem casamento por prefixo. URI não cadastrada recusa a criação na hora, com o novo erro 400 invalid_callback_uri — e não no fim da jornada.
Os parâmetros da URI não são prova de nada. Eles viajam na barra de endereço e o próprio titular pode editá-los; servem para o seu app escolher que tela mostrar. Qualquer decisão com efeito continua dependendo do webhook ou de GET /v1/accreditations/{accreditationId}. E outcome=biometry_approved quer dizer que a etapa de biometria terminou, não que a conta está ativa: a ativação continua chegando em accreditation.active.
Novo campo personId em persons[], na resposta da criação e da consulta. É o identificador estável de cada pessoa dentro do credenciamento, e é ele que aparece na URI de retorno — CPF não vai para uma URI que fica em histórico de navegador e log de proxy. Campo adicional: nada do que você já lê mudou.
Sem callbackUri, nada muda em nenhum dos fluxos.

v2.49.1 (2026-08-07) - `account_not_entitled` passa a valer também no extrato e no saldo diário

O extrato e o saldo diário ainda respondiam 502 partner_unauthorized no caso que a v2.49.0 anunciou como 409 account_not_entitled. O código de erro entrou no ar naquela versão, mas essas duas consultas seguiam devolvendo o 502 com a mensagem "tente novamente em alguns minutos" — falsa para esta condição, que é permanente até o liquidante habilitar o serviço para a conta.
Agora GET /v1/accounts/{accountId}/statement e GET /v1/accounts/{accountId}/daily-balance respondem 409 account_not_entitled nesse cenário, como as demais operações da API. Trate como erro definitivo — acione o suporte informando o accountId — e não como indisponibilidade transitória. Descrição completa em Erros.
O 502 partner_unauthorized continua existindo, sem mudança, para a falha legítima de autenticação da CorpX no liquidante.

v2.49.0 (2026-08-06) - Serviço não habilitado na conta deixa de parecer falha temporária nossa

Novo código de erro account_not_entitled (HTTP 409, não repetível). Ele aparece quando o credenciamento da conta está concluído, mas o liquidante não habilitou aquela operação para ela — as demais operações da mesma conta seguem funcionando normalmente. A condição é permanente até a habilitação ser feita do lado do liquidante: repetir a chamada não resolve. Ao receber esse erro, acione o suporte informando o accountId. Descrição completa em Erros.
Esse caso saía como 502 partner_unauthorized, que dizia o contrário. Aquela mensagem afirmava que a credencial da CorpX havia sido recusada e que era para tentar de novo em alguns minutos — duas coisas falsas para esta situação, e que levavam o integrador a repetir a chamada indefinidamente. O 502 partner_unauthorized continua existindo, sem mudança, para a falha legítima de autenticação da CorpX no liquidante.
Se você trata 502 nessa rota com retry, revise. A resposta desse cenário passa a ser 409, e deve ser tratada como erro definitivo (abrir chamado), não como indisponibilidade transitória.

v2.48.0 (2026-08-06) - Recusa do liquidante deixa de ser lida como limite da sua conta

Novo código de erro partner_rate_limited (HTTP 429, repetível). Quando o liquidante recusa a chamada por excesso de requisições, a resposta passa a ser 429 partner_rate_limited. Antes esse caso chegava como 422 limit_exceeded, que quer dizer "o valor da operação excedeu um limite configurado na conta" — ou seja, mandava você conferir os limites da conta quando o que havia sido atingido era apenas a cadência de chamadas. Nada no seu pedido está errado nesse erro: reduza o ritmo e repita com backoff. Descrição completa em Erros.
Chave PIX inexistente na consulta passa a responder 404 key_not_found. Em GET /v1/accounts/{accountId}/pix/key/{pixKey}, a chave que não existe no DICT vinha como 400 partner_error, o código genérico de falha de comunicação. Agora vem o 404 key_not_found que a referência já documentava, e que você pode tratar sem inspecionar a mensagem. Se o seu código identificava a chave inexistente pelo texto dentro do 400, passe a tratar o 404. A consulta de QR Code inexistente não muda: continua 404 not_found.
Recusa do liquidante sem corpo de resposta deixa de sair como 401 com message vazia. Agora ela vem como 502 partner_unauthorized, com a message preenchida dizendo que o liquidante recusou a chamada e não devolveu corpo. O 401 fazia parecer que a sua credencial havia sido recusada, quando a autenticação em jogo é a da CorpX com o liquidante — o integrador ia investigar do lado errado. 401 e 403 continuam sendo sempre sobre a sua credencial e as suas permissões.
O 429 na consulta de chave passa a ter dois significados, distinguidos pelo errorCode. dict_lookup_limit_exceeded é a cota de consultas da sua conta, e a message diz qual contador fechou — ver Políticas e Regras. partner_rate_limited não tem relação com a sua cota: é throttling do liquidante sobre o tráfego da CorpX. Se o seu tratamento de 429 nessa rota hoje olha só o status, passe a olhar o errorCode antes de concluir que a cota da conta acabou.

v2.47.0 (2026-08-06) - O piso do ratio cai para 50 e o default do `maxLookupRatio` sobe para 4

O teto do maxLookupRatio fica mais apertado para quem consulta muito e transfere pouco. O teto do ratio é transferências com sucesso nas últimas 24h × maxLookupRatio, e ele nunca cai abaixo de um piso — a rede de segurança que permite a uma conta nova consultar a chave do primeiro pagamento. Esse piso era de 500 consultas/24h e passa a ser de 50 consultas/24h, por conta. É um aperto, não um afrouxamento: contas cujo teto até aqui vinha do piso passam a ter um teto menor.
Na prática, o ratio volta a ser um limite que decide. Com o piso em 500, e como vale sempre o mais restritivo, quem batia em algum limite batia no teto diário — o maxLookupRatio quase nunca chegava a ser o limite aplicado. Com o piso em 50, o teto de consultas volta a acompanhar o volume de transferências da conta, que é o propósito do ratio.
O default global do maxLookupRatio sobe de 1,2 para 4. O default é o valor que vale para a conta que não tem esse limite escrito na própria policy. Enquanto o piso era alto, ele mascarava o default: o ratio quase nunca chegava a decidir, e por isso 1,2 nunca incomodou. Com o piso em 50 o ratio passa a decidir de verdade, e 1,2 barraria quem consulta pouco mais de uma vez por transferência — um padrão de uso normal, de quem consulta a chave para conferir o destinatário antes de pagar. Em 4, o teto acompanha o uso real. Se a sua conta tem maxLookupRatio na policy, nada muda para você: o valor configurado continua vencendo o default.
O que fazer. Se a sua integração consulta chaves muito acima do número de pagamentos que realiza, revise o padrão de consulta (o cache de 24h não consome cota) ou peça revisão dos limites da sua conta. Quando é o piso que decide, a mensagem do 429 dict_lookup_limit_exceeded diz (bootstrap floor of 50 lookups/24h applied). A tabela com os defaults de cada limite está em Políticas e Regras, e o piso em Piso de 50 consultas/24h no ratio.

v2.46.0 (2026-08-05) - Todo limite de consulta de chave passa a ser medido por conta

Os limites de consulta de chave PIX passam a ser contados por conta, sempre. Os quatro limites (maxLookupsPerDay, maxLookupRatio, maxLookupsPerMinute e maxNotFoundPer5min) são medidos conta a conta: as consultas de uma conta nunca entram na contagem de outra, mesmo que as duas pertençam ao mesmo tenant. A conta é a unidade que o próprio DICT mede, então é nela que o limite passa a valer.
Uma policy configurada no tenant vale para cada conta individualmente. Um maxLookupsPerDay: 50 na policy do tenant significa "cada conta pode fazer 50 consultas por dia", e não "50 por dia divididas entre as contas" — a policy de tenant é um molde aplicado a cada conta, não um balde compartilhado. Se você dimensionou o número pensando no consumo somado do tenant, revise-o: o teto efetivo ficou maior. A policy de conta continua vencendo a do tenant quando existir. Detalhes em Políticas e Regras.
O teto do maxLookupRatio passa a contar só as transferências que aconteceram. O denominador do ratio agora considera apenas as transferências concluídas da própria conta (incluindo as que foram devolvidas depois). Pagamento que falhou ou foi recusado não amplia mais o teto — antes, repetir uma tentativa com erro aumentava a cota de consulta a cada falha. O piso de 500 consultas por 24h continua valendo, agora por conta.
Consultas de chave feitas dentro de um PIX Out passarão a consumir cota. Ao pagar no modo KEY, a chave precisa ser resolvida antes de o dinheiro sair, e essa pergunta vai para o mesmo DICT da consulta explícita. Nesta versão o comportamento está desligado por padrão e é controlado por configuração; nada muda para você agora, e avisaremos antes de qualquer virada. Quando ativo, um PIX Out pode responder 429 dict_lookup_limit_exceeded — e nesse caso nenhum pagamento é criado, sem paymentId e sem transação, então reenviar com a mesma Idempotency-Key continua seguro. O cache de 24h é compartilhado entre os dois caminhos, de modo que consultar a chave e em seguida pagar gasta uma consulta, não duas; o BigPix resolve a chave uma vez para o lote inteiro. Ver Políticas e Regras.
company.tradeName passou a ser obrigatório em POST /v1/accreditations/pj (registrado aqui depois da publicação da versão). O liquidante exige nome fantasia para CNPJ e recusava o credenciamento no fim da jornada, depois da biometria e da análise; agora a recusa vem na criação, com 400 missing_fields. Se a empresa não tiver nome fantasia registrado, repita a razão social. Ver Abertura de Conta PJ.

v2.45.1 (2026-08-05) - Chave inexistente no DICT volta a ser reconhecida como tal

Corrigido: chave PIX que não existe era reportada como not_found genérico. Numa transferência por chave, a chave inexistente vinha com o código de recurso não encontrado, o mesmo que qualquer outro recurso ausente. Agora vem key_not_found, que é o código específico já descrito em Erros — dá para tratar "chave errada" sem inspecionar a mensagem.
A detecção de varredura de chaves volta a funcionar. O limite de consultas sem resultado numa janela de 5 minutos dependia dessa classificação e, por causa do mesmo defeito, nunca disparava. Quem consulta muitas chaves inexistentes em sequência passa a receber 429 dict_lookup_limit_exceeded com a mensagem de padrão de varredura. Os limites da sua conta estão em Políticas e Regras.

v2.45.0 (2026-08-05) - Conta ainda em credenciamento responde `409`, não erro de comunicação

Novo código de erro account_not_ready (HTTP 409). Quando a conta existe no CorpX mas o credenciamento dela ainda não foi concluído, qualquer operação bancária nela passa a responder 409 account_not_ready. Antes essas chamadas caíam em 502 partner_error, o que fazia parecer instabilidade da API quando na verdade era estado esperado do onboarding. A lista completa está em Erros.
GET /v1/accounts/{accountId}/balance deixa de devolver saldo zero nesse caso. A resposta era 200 com total, available e locked em zero, o que se confunde com conta vazia. Agora vem o mesmo 409 account_not_ready. Se o seu código trata saldo zero como "conta sem dinheiro", trate 409 como "conta ainda não operacional" e acompanhe a accreditation até ACTIVE antes de operar.

v2.44.3 (2026-08-05) - Consulta de chave recusada passa a consumir a cota diária

Corrigido: consulta de chave PIX recusada não descontava da cota. Quando o DICT recusava a consulta — por chave malformada ou por limite atingido do lado dele —, a chamada não entrava no contador diário nem no de proporção. Na prática, um laço de repetição sobre uma chave que sempre falha rodava sem encontrar teto. Agora essas recusas consomem cota como qualquer outra consulta, e o laço passa a receber 429 dict_lookup_limit_exceeded ao atingir o limite da conta.
Falha nossa continua sem cobrar cota. Indisponibilidade ou tempo esgotado na consulta segue fora do contador: você não perde cota por incidente que não é seu.
O que fazer se você recebe 429 agora. Trate a recusa da chave como definitiva em vez de repetir a mesma consulta. Os limites da sua conta estão em Políticas e Regras.

v2.44.2 (2026-08-05) - Pagamento de QR Code sem identificador deixa de passar em branco

Corrigido: crédito de QR Code sem identificador não gerava webhook nenhum. Quando o pagamento chegava por um BR Code que não carrega identificador — o caso típico do código estático montado fora da API, com *** no campo de txid —, nem qrcode.paid nem pix.in.completed eram entregues. O dinheiro entrava na conta e só aparecia no extrato. Agora os dois eventos são entregues normalmente, com identifier vazio e method igual a STATIC_QR_CODE. Use o endToEnd como chave de deduplicação nesses créditos, já que não há identificador para amarrar.
Novo Guia de QR Code Estático. Cobre criação, recebimento por webhook, conciliação e cancelamento, e explica por que gerar o código pela API em vez de montar o BR Code por conta própria.

v2.44.1 (2026-08-05) - `method` do PIX recebido diz se veio de QR Code

Corrigido: method chegava vazio em pix.in.completed. O campo existia no payload mas nunca vinha preenchido, então não dava para saber pelo webhook se o crédito veio de um QR Code ou de uma chave PIX. Agora ele vem sempre com STATIC_QR_CODE, DYNAMIC_QR_CODE ou DICT (chave PIX ou dados bancários).
O extrato passa a refletir o mesmo método. Antes todo PIX recebido aparecia como DICT no GET /v1/accounts/{accountId}/statement, inclusive os pagos por QR Code. Lançamentos anteriores a esta versão não foram reprocessados.
Regras de política por método valem para PIX recebido. Uma regra da seção pixIn condicionada ao método nunca casava, porque o método chegava vazio na avaliação.

v2.43.4 (2026-08-03) - Credenciamento não é mais recusado por complemento curto

Corrigido: credenciamento recusado por causa do complemento do endereço. Um complemento com menos de três caracteres (por exemplo A) fazia a abertura de conta ser recusada no fim do fluxo, depois da biometria. Como o complemento é opcional, agora ele é omitido no envio quando é curto demais e a conta é criada normalmente.
Recusa de campo agora diz qual campo e qual o limite. Parte das recusas de validação chegava como uma mensagem genérica pedindo para revisar o payload. Agora a resposta traz errorCode invalid_field, o campo em partner.field e a mensagem com o limite esperado.

v2.43.3 (2026-08-03) - Reenvio de pagamento recusado volta a executar

Corrigido: reenviar um pagamento recusado com a mesma Idempotency-Key agora executa de novo. Em algumas recusas — a mais comum sendo a conta sem saldo — o reenvio com a mesma chave não reexecutava o pagamento e deixava a operação parada em PENDING. A única saída era emitir com uma chave nova. Agora toda recusa definitiva libera o reenvio, reaproveitando o mesmo paymentId.
A resposta de recusa ficou consistente. O 422 traz sempre paymentId, status, errorCode, errorReason e completedAt, no mesmo formato independentemente do motivo da recusa.
Nada muda no TIMEOUT. Quando o desfecho é indeterminado, o reenvio com a mesma chave continua devolvendo o estado existente sem submeter o pagamento outra vez — confira o extrato antes de emitir com uma chave nova.

A página de Idempotência foi reescrita com o comportamento de cada cenário (sucesso, recusa, em andamento, TIMEOUT, chave nova) e o que cada fluxo usa para deduplicar — PIX, transferência interna, boleto e TED têm regras diferentes.

v2.43.1 (2026-07-31) - Credencial de recebimento sem acesso a saldo e extrato

read deixou de ser obrigatório. Ele passa a valer só para as consultas amplas da conta (saldo, extrato, timeline, lançamentos) e é opcional na criação da credencial. Antes toda credencial saía com read, o que impedia exatamente o caso que a granularidade existe para atender.
Cada escopo consulta o próprio domínio. qrcode.manage sozinho cria o QR e vê se foi pago; pix_keys.manage lista as chaves; exports.create baixa o arquivo; webhooks.manage acompanha as entregas; med.defend consulta os MEDs. Nos escopos de cashout, o mesmo vale para o status da própria operação.
qrcode.manage + uma conta é agora uma credencial que cobra por QR code naquela conta e não enxerga mais nada.
Credenciais já emitidas não mudam — as criadas ontem mantêm o read que receberam. Para restringir, emita uma nova credencial e revogue a antiga.

Detalhes no Guia de Autenticação.

v2.43.0 (2026-07-31) - Escopos granulares nas credenciais de integração

Você escolhe o que cada credencial pode fazer. Ao criar uma credencial no painel (API Credentials), o tenant manager marca os escopos: read, qrcode.manage, pix_keys.manage, webhooks.manage, exports.create e med.defend. A credencial que não tem o escopo da rota recebe 403 insufficient_scope nomeando o escopo que falta.
Uma credencial de QR code enxerga o pagamento do próprio QR. qrcode.manage cobre criar, cancelar e consultar o QR (GET .../pix/qr-code/lookup), então dá para ter uma credencial de cobrança sem acesso a saldo e extrato.
Restrição por conta. A credencial pode ficar limitada a contas específicas do tenant — é o caminho para dar a um subsistema acesso a uma conta só. Nenhum usuário emite credencial mais ampla do que o próprio acesso dele.
Escopos que movimentam dinheiro são emitidos pela CorpX (pix_out.create, refund.create, internal_transfer.create, ted.create, boleto_payment.create, med.decide). Pedir um deles pelo painel devolve 403 scope_not_self_service.
Credenciais existentes não mudam. Quem já integra segue com acesso total (api2/read api2/write) e não precisa fazer nada.

Detalhes no Guia de Autenticação.

v2.42.0 (2026-07-30) - Suspensão temporária de acesso por pendência

Dois códigos novos: tenant_suspended e tenant_disabled. Quando há uma pendência em aberto, o acesso do tenant pode ser suspenso temporariamente. Com o tenant suspenso, as consultas (GET) continuam funcionando — saldo, extrato e status de operações — e as escritas respondem 403 tenant_suspended. Com o tenant desativado, todas as rotas respondem 403 tenant_disabled.
A credencial não é revogada. O mesmo client_id/client_secret continua obtendo token normalmente; a recusa acontece na chamada à API. Regularizada a pendência, o acesso volta na chamada seguinte — sem credencial nova, sem token novo.
Dinheiro recebido continua entrando. PIX recebido segue sendo creditado e os webhooks desses eventos continuam sendo entregues. A suspensão bloqueia iniciar novas operações, não receber.

Detalhes no Guia de Autenticação.

v2.41.1 (2026-07-30) - Transferência interna recusada não volta mais como pendente

Recusa do liquidante agora responde 422. POST /v1/accounts/{accountId}/transfers/internal (e as variantes /by-document e /by-bank-account) devolvia 202 com status: "PENDING" quando o liquidante recusava a operação — a transferência estava definitivamente encerrada, mas a resposta pedia para esperar. Agora a recusa sai como 422 com status: "FAILED", errorCode e errorReason, como o contrato já documentava. O 202 PENDING ficou reservado ao caso indeterminado (a operação ainda em curso quando a janela síncrona expira).
insufficient_funds no lugar de partner_rejected quando o motivo é saldo. O liquidante recusa transferência interna por falta de saldo com uma mensagem genérica ("o liquidante recusou a operação"). Passamos a conferir o saldo disponível na hora da recusa: quando ele não cobre o valor pedido, a resposta vem como insufficient_funds. Sem essa evidência a recusa continua partner_rejected, com o motivo do liquidante no bloco partner.
workflowId correto na transferência interna. Repetir o POST com a mesma Idempotency-Key devolvia um workflowId com prefixo de PIX out. Agora vem o id real da operação (internal-out-…).
TED não fica mais eternamente em PROCESSING. O desfecho do liquidante chegava, mas era entregue ao processo errado e se perdia — e o registro da TED nunca era atualizado. Resultado: GET /transfers/ted/{tedId} e o extrato mostravam "processando" mesmo em TED já liquidada ou recusada, e uma recusa só virava ted.out.failed 48h depois, com o motivo genérico de timeout no lugar da recusa real. Agora o desfecho é aplicado assim que chega, e as TEDs que estavam presas foram conciliadas com o estado real.
TED: bankCode só aceita o Compe de 3 dígitos. Mandar o ISPB (8 dígitos) nesse campo agora é recusado na hora com 400 invalid_bank_code. Antes a requisição era aceita com 202, seguia para o liquidante sem banco de destino e a TED ficava presa em PROCESSING — sem liquidar e sem falhar. O ISPB continua válido no PIX por dados bancários (bankIspb).

Transferência interna não tem webhook de falha

O webhook transfer.internal.out só é entregue quando a transferência é efetivada. Para uma recusa, o desfecho está na resposta da própria chamada — por isso o 422 acima importa. Não espere webhook para fechar uma transferência interna recusada.

v2.41.0 (2026-07-29) - Estorno parcial de PIX recebido

Devolução parcial liberada. POST /v1/accounts/{accountId}/pix/out/refund passa a aceitar amount menor que o valor do PIX original — antes só o valor integral era aceito e qualquer valor menor era recusado com 400 partial_refund_not_supported. Acima do original a resposta continua sendo 400 refund_amount_exceeded.
Um mesmo PIX pode ser devolvido em parcelas, até somar o valor original. Cada devolução precisa de Idempotency-Key e identifier próprios: repetir um deles faz a API devolver o resultado da devolução anterior em vez de iniciar uma nova. O saldo ainda devolvível é controlado pelo liquidante — uma parcela que o estoure volta como refund_amount_exceeded. Para saber quanto já foi devolvido, consulte o extrato: as linhas de devolução referenciam o E2E da transação original.
partial_refund_not_supported deixou de ser retornado. O código continua documentado para não quebrar quem já o trata, mas nenhuma resposta o usa mais.
Timeline mais informativa na devolução. O evento pix_out.requested de uma devolução ganhou dois campos opcionais: originalAmount (valor do PIX devolvido) e partialRefund (true quando o estorno é parcial).
mode: "REFUND" só vale na rota dedicada. POST /v1/accounts/{accountId}/pix/out e sua versão async passam a responder 400 invalid_field quando recebem esse modo no body — a devolução precisa do contexto que só /pix/out/refund resolve. Fluxos que dependiam disso devem migrar para a rota dedicada.

v2.40.0 (2026-07-29) - Todas as regras do painel passam a valer

PIX recebido passa a ser avaliado. A seção PIX In do painel ganhou motor: whitelist e blacklist de CPF/CNPJ do pagador, mesma titularidade, limite de valor, tipo de pessoa e bancos permitidos/bloqueados. Um PIX recebido não pode ser recusado — o liquidante credita a conta e só depois nos avisa —, então a avaliação acontece após o crédito, com duas ações possíveis: ALLOW_AND_NOTIFY (padrão: credita e avisa) e AUTO_REFUND (credita, avisa e devolve o valor integral automaticamente). O pix.in.completed continua sendo entregue nos dois casos, antes do aviso de violação.
Criação de QR Code passa a respeitar a policy. canCreateStatic, canCreateDynamic, minAmount e maxAmount agora recusam a criação com 422 policy_denied na resposta do POST. QR estático sem valor (aberto, em que o pagador escolhe quanto pagar) não é avaliado pelos limites de valor, porque não há valor a comparar.
Criação de chave PIX passa a respeitar a policy. canCreate e maxKeys recusam a criação com 422 policy_denied. O limite conta as chaves que a conta já tem; se a contagem não puder ser feita no momento, a criação segue — falha de consulta não vira recusa.
Estorno passa a respeitar a policy. enabled e maxAmount da seção Estorno recusam a devolução pedida pela API em POST /pix/out/refund com 422 policy_denied. Devolução regulatória (MED) não é afetada.
policy.violation cobre todos os domínios. phase ganhou o valor pix_in e action ganhou ALLOW_AND_NOTIFY e AUTO_REFUND. Em violação de PIX recebido o payload traz transactionId, endToEnd e refunded no lugar de paymentId, e o pagador vem em counterparty. As regras das novas seções são prefixadas (pixIn.*, qrCode.*, keys.*, refund.*); as de PIX out seguem sem prefixo.
Ações que nunca puderam ser cumpridas foram removidas do painel. PIX In não oferece mais BLOCK nem QUARANTINE (e o campo de dias de quarentena saiu): não há como segurar dinheiro que já foi creditado. Configuração antiga com essas ações passa a valer como ALLOW_AND_NOTIFY, ou seja, avisa em vez de prometer bloqueio.
Campos e seções sem efeito foram removidos. Saíram do painel e da documentação os campos de PIX Out requireApprovalAbove, chunkSize, duplicateGuardSecs e syncRateLimitPerMin, além das seções MED e IP allowlist — o controle de IP é feito na configuração de rede da sua conta, não aqui. Com isso, a seção "Seções não aplicadas" do guia de Políticas e Regras deixou de existir: tudo o que o painel oferece é aplicado.

v2.39.0 (2026-07-29) - Erros do liquidante deixam de ser genéricos

Recusa do liquidante agora tem código próprio. Antes, qualquer falha do banco parceiro chegava como partner_error (502) nas chamadas síncronas e como invalid_payload nos casos 4xx, sem dizer o que corrigir. Agora o motivo vem no errorCode: limit_exceeded_daily, limit_exceeded_nightly, limit_exceeded_monthly, limit_exceeded_transaction, pix_key_limit_exceeded, recipient_account_not_found, identifier_conflict, balance_reservation_failed, boleto_already_settled, boleto_scheduled, boleto_amount_mismatch, qr_gone, qr_amount_mismatch, invalid_field, key_ownership_mismatch, partner_account_disabled, entre outros. A lista completa está em Tratamento de Erros e é gerada a partir do catálogo do próprio código.
Novo bloco partner na resposta e nos webhooks. Junto do nosso código e da nossa mensagem em PT-BR, a resposta traz partner.code, partner.message e partner.field crus do liquidante, para diagnóstico sem abrir ticket. Nos webhooks de falha ele vem em data.partner. É informativo: continue tratando pelo errorCode.
Mudança de status HTTP nos limites. Limite estourado saía com o 403 do liquidante, que muitos clientes leem como falha de autenticação; agora sai como 422. QR Code removido, que saía como 410, passa a 409. Erros 5xx do liquidante seguem como 502.
Mensagem acionável em vez da mensagem crua. errorReason nos webhooks e no detalhe da transação passa a trazer a nossa mensagem em PT-BR — com o limite restante e o nome do campo quando o liquidante informa — em lugar do texto original do parceiro.
Credenciamento com motivo específico. accreditation.failed e GET /v1/accreditations/{id} passam a distinguir partner_validation_failed (com o campo recusado na mensagem), partner_unavailable (transitório, dá para reenviar) e existing_partner_account, em vez de colapsar tudo em recusa genérica.
Limites conhecidos do liquidante validados no POST. address.number acima de 10 caracteres, address.cityIbgeCode incoerente com address.state, description acima de 140 caracteres e agência acima de 4 dígitos passam a ser recusados na hora, com 400 invalid_field, em vez de derrubarem a operação — ou a jornada de credenciamento, depois da biometria — no liquidante.
Catálogo de erros publicado corrigido. Os códigos que a documentação listava e a API nunca emitiu (pix_limit_exceeded, pix_qr_expired, pix_qr_not_found, pix_qr_already_paid, pix_qr_cancelled, pix_key_not_found, pix_key_already_exists, insufficient_balance, invalid_key_type, invalid_emv, refund_not_allowed, med_*, missing_idempotency_key, invalid_signature, authz_error) foram removidos. Saldo insuficiente do liquidante é insufficient_funds; chave inexistente no DICT é key_not_found.

v2.38.0 (2026-07-28) - Regras de PIX out passam a valer, com aviso por webhook

As regras de PIX out configuradas no painel passam a ser aplicadas. Kill switch, whitelist, blacklist, mesma titularidade, horário de operação, limite por transação, limite noturno e tipo de destinatário (PF/PJ) agora recusam a transferência que as viola. Nada muda para quem não tem regra configurada: a regra passa a valer no momento em que é salva.
Novo erro 422 policy_denied. A recusa vem no POST com a lista de regras violadas em violations, cada uma com rule e message. Não é 403 nem 400: a requisição está correta e foi recusada por uma regra do próprio tenant.
Regras que dependem do destinatário são avaliadas depois de resolvê-lo. Nos modos chave e QR Code o documento do recebedor só existe após a consulta ao DICT ou a decodificação do BR Code. Nesses casos o pagamento é aceito no POST e termina como FAILED com errorCode: policy_denied, com pix.out.failed na timeline e no webhook.
Novo evento de webhook policy.violation. Enviado em toda violação, com phase (edge, counterparty ou dict_lookup), action, blocked, amount, as regras violadas e a contraparte quando conhecida. Passa a valer também para consultas de chave PIX recusadas por limite, que antes só devolviam 429. Quem já assinava o evento começa a recebê-lo sem alterar a subscription.
Modo monitor (NOTIFY_ONLY). A seção PIX Out ganhou o campo violationAction: em NOTIFY_ONLY a violação é registrada e avisada por webhook, mas o pagamento segue. É o ensaio recomendado antes de promover a regra para BLOCK.
Documentação honesta sobre o que é aplicado. O guia de Políticas e Regras agora separa as regras que o motor avalia das seções que ficam apenas salvas na configuração (PIX in e suas ações, QR Code, chaves, estorno, MED, IP allowlist). Também corrigimos a informação de que violações apareceriam no extrato: um PIX out recusado nunca chega ao banco parceiro e, portanto, não aparece lá.

v2.37.3 (2026-07-28) - Correção: PIX out por QR Code sem valor

Pagamento de QR Code sem amount voltou a funcionar. Quando o BR Code já carrega o valor, o campo amount pode ser omitido no pagamento. Nesses casos o pagamento não era efetivado e a transação ficava parada como pendente, sem nunca receber um desfecho. Agora o valor do BR Code é utilizado e o pagamento segue normalmente.
Toda transação passa a terminar com um desfecho. Falhas que aconteciam antes do envio ao liquidante não geravam pix.out.failed nem entrada na timeline, e a transação ficava pendente indefinidamente. Agora esses casos são encerrados com pix.out.failed, com errorCode e errorReason preenchidos, tanto no webhook quanto na timeline.
Nesses pagamentos por QR Code, o amount publicado no webhook e na timeline reflete o valor efetivo cobrado pelo BR Code.

v2.37.2 (2026-07-28) - Correção: `ted.in.received` voltou a ser entregue

TED recebida voltou a gerar webhook. Desde 22/07 o liquidante passou a enviar as notificações de TED em um formato em que a direção vem só no campo Flow, e toda TED recebida era interpretada como atualização de TED enviada. Resultado: nenhum ted.in.received era despachado e o crédito não aparecia no extrato da API (o saldo e o extrato do liquidante sempre estiveram corretos).
O evento agora é classificado pela direção informada pelo liquidante e entregue normalmente a quem assina ted.in.received.
As TEDs recebidas entre 22/07 e 28/07 foram reprocessadas: os webhooks chegam com o payload original e a data (receivedAt) do crédito.

v2.37.1 (2026-07-26) - Portabilidade automática passa a depender de habilitação

A jornada de autorização do titular (PENDING_CONSENT + consentLink, lançada na 2.37.0) agora é habilitada por tenant, mediante contrato, e não vem ligada. Ela transfere o controle do dinheiro de uma conta que já existe, então deixou de ser automática para todo integrador de onboarding.
Sem a habilitação, POST /v1/accreditations/pf com CPF que já tem conta volta ao comportamento anterior: a accreditation termina em FAILED com errorReason=existing_partner_account e a mensagem orienta o titular a solicitar a portabilidade ao suporte, que conduz o processo.
Nada muda para quem já tem a portabilidade habilitada.
Para habilitar, fale com o seu contato comercial na CorpX.

v2.37.0 (2026-07-25) - Abertura PF de CPF que já tem conta (autorização do titular)

POST /v1/accreditations/pf com um CPF que já é correntista deixa de falhar com existing_partner_account. A accreditation nasce em PENDING_CONSENT e a resposta traz persons[].consentLink: uma página em que o próprio titular autoriza o seu tenant a operar a conta que ele já tem.
Na página, o titular vê o que está autorizando (inclusive movimentar e sacar), passa por verificação de identidade (selfie com prova de vida validada contra bases oficiais pelo CPF) e só então vê número da conta e saldo atual para autorizar. O aceite é registrado com data, hora, dispositivo e o saldo exibido.
Autorizado, você recebe accreditation.active com sharedAccount: true e um accountId para operar. É a mesma conta: saldo, extrato e chaves Pix são os que já existiam.
Contas compartilhadas: quem já operava a conta continua operando. Todos os tenants autorizados pelo titular recebem os webhooks de cada movimento; operações originadas fora da sua API chegam com external: true.
Novos eventos: accreditation.consent.link.created (link de autorização gerado) e account.shared_access.granted (outro tenant passou a operar uma conta que você já operava).
Novos errorReason em accreditation.failed: consent_declined, consent_expired, consent_identity_failed, consent_link_failed.
POST /v1/accreditations/{id}/cancel e POST /v1/accreditations/{id}/persons/{cpf}/retry passam a aceitar PENDING_CONSENT (cancelar a jornada / reemitir o link).
O titular pode revogar o acesso concedido pelo suporte; a partir daí as chamadas do tenant revogado para aquela conta respondem 403.
Detalhes em Titular que já tem conta.

v2.36.1 (2026-07-25) - `pixLimits` removido do accreditation

O campo pixLimits deixou de ser aceito em POST /v1/accreditations/pf e POST /v1/accreditations/pj.
Na abertura da conta, os limites PIX seguem os padrões conservadores aplicados automaticamente.
Qualquer alteração de limite (aumento ou redução) continua exigindo solicitação manual ao suporte.

v2.36.0 (2026-07-25) - API de alteração de limites PIX desativada

A API de redução de limite PIX foi desativada (PATCH /v1/accounts/{accountId}/pix/limits).
A partir de agora, todas as alterações de limite (aumento e redução) precisam de solicitação manual ao suporte.
GET /v1/accounts/{accountId}/pix/limits continua disponível para consulta.

v2.35.0 (2026-07-23) - Webhooks de MED (disputas) voltaram

Os webhooks pix.med.opened e pix.med.updated voltaram a ser emitidos: você é notificado quando uma disputa (MED) é aberta contra um PIX creditado na sua conta e quando ela muda de status.
O payload traz medId, originalEndToEnd (o PIX em disputa), amount, reasonCode e status (OPEN, PENDING_DECISION, ACCEPTED, REJECTED, CANCELED). Veja Webhooks.
No Portal do Integrador, pix.med.opened / pix.med.updated deixam de aparecer como "em breve" e já podem ser assinados.
A contestação via API (GET /pix/med, answer, decide, evidence/*) segue temporariamente em 503 — apenas as notificações voltaram.

v2.34.3 (2026-07-23) - Tarifas CorpX no extrato sem prefixo `fee-*`

Transferências internas de tarifa CorpX no extrato passam a ser classificadas como FEE mesmo quando o identifier não usa o prefixo fee-* (casos em que o liquidante só envia o UUID da operação). O filtro e a exibição de tarifas no extrato ficam consistentes.

v2.34.2 (2026-07-23) - Entrega confiável dos webhooks de TED

Webhooks ted.in.received, ted.out.confirmed e ted.out.failed passam a ser entregues de forma confiável quando uma TED é creditada na sua conta ou quando a TED que você enviou é liquidada/rejeitada.
Em ted.in.received, data.payer (nome, documento, banco, agência, conta) é preenchido quando o liquidante informar esses dados.
Em ted.out.failed, data.errorReason passa a vir preenchido quando o liquidante informar o motivo da rejeição.

v2.34.1 (2026-07-23) - `payer`/`payee` em `pix.refund.completed` externo

Webhooks pix.refund.completed e pix.refund.failed de devoluções iniciadas fora da API (data.external: true) passam a incluir data.payer e data.payee (nome, documento, banco, agência, conta), alinhados ao contrato documentado e ao payload de pix.out.*.
Quando disponível, data.identifier também é preenchido.

v2.34.0 (2026-07-23) - Documentos societários no accreditation PJ

POST /v1/accreditations/pj aceita company.legalForm (mei | ltda | sa | cooperative; default ltda).
Novo POST /v1/accreditations/{id}/documents: upload PDF (presign) dos kinds company_articles, company_proof_of_address, cnpj_card, financial_statements, business_license, regulatory_license, other.
PENDING_REVIEW após biometrias aprovadas. PDFs obrigatórios por legalForm (MEI/LTDA: articles + proof_of_address; SA/cooperativa:
- cnpj_card + financial_statements); validade conferida pelo operador.
Approve com docs faltando retorna 409 documents_incomplete, salvo forceIncompleteDocuments=true + reason (auditoria em documentsOverride*).
GET de accreditation PJ passa a expor legalForm, documents, requiredDocumentKinds, missingDocumentKinds.
Em cooperative, partners[] são os diretores estatutários (doc).

v2.33.2 (2026-07-21) - Guard de destino ambíguo na transferência interna por documento

POST /v1/accounts/{accountId}/transfers/internal/by-document: quando o documento de destino possui mais de uma conta ativa, a requisição passa a ser rejeitada com 409 multiple_destination_accounts em vez de transferir para uma conta escolhida automaticamente. Endereçe a transferência via /transfers/internal/by-bank-account (agência + conta) ou /transfers/internal (destinationAccountId).

v2.33.1 (2026-07-21) - Link de aceite BYO + webhooks de accreditation

GET/POST de accreditation no fluxo BYO passam a devolver persons[].acceptanceLink (a URL da página de aceite), além de linkExpiresAt / acceptanceStatus.
Eventos de accreditation passam a aparecer em GET /v1/webhooks/events e no portal (Settings → Webhooks): accreditation.pf.created, accreditation.pj.created, accreditation.biometry.link.created, accreditation.acceptance.link.created, accreditation.updated, accreditation.active, accreditation.failed.
accreditation.pf.created / accreditation.pj.created passam a ser emitidos de fato na criação (confirmação assíncrona do POST).

v2.33.0 (2026-07-21) - Cancelamento de accreditation + docs sem dedup

Novo endpoint POST /v1/accreditations/{accreditationId}/cancel: cancela accreditation ainda em PENDING_BIOMETRY (antes do vínculo do CPF/CNPJ ao tenant). Termina como FAILED com errorReason=cancelled.
Documentação/OpenAPI/Postman deixam explícito que POST /v1/accreditations/pf|pj não deduplica: repetir o mesmo documento enquanto pendente cria outra accreditation (201); depois da biometria, documento já claimado retorna 409 already_accredited.

v2.32.0 (2026-07-19) - Deprecação do PIX out QR Code síncrono

POST /v1/accounts/{accountId}/pix/out/qr-code (sync) e o alias /pix/out/qrcode passam a retornar headers Deprecation, Sunset e Link (sucessor: /pix/out/qr-code/async; sunset previsto 2026-11-21).
O fluxo canônico de pagamento EMV (copia e cola) é POST .../pix/out/qr-code/async (202 + webhooks).
Documentação, OpenAPI e Postman atualizados para priorizar o async.

v2.31.0 (2026-07-19) - PIX out QR Code (copia e cola) assíncrono

Novo endpoint POST /v1/accounts/{accountId}/pix/out/qr-code/async: agenda o pagamento de um EMV (copia e cola) e responde 202 na hora, no mesmo padrão do PIX out por chave (/pix/out/async).
O resultado final chega por webhook (pix.out.completed, pix.out.failed, pix.out.timeout) ou via lookup por identifier.
O endpoint síncrono POST .../pix/out/qr-code continua disponível e sem mudança de comportamento.

v2.30.0 (2026-07-18) - Onboarding: CPF/CNPJ só atrela ao tenant após biometria

POST /v1/accreditations/pf|pj não cria mais conta nem reserva o documento enquanto o status é PENDING_BIOMETRY.
O accountId passa a existir só depois da biometria/aceite confirmado (transição para BIOMETRY_APPROVED em diante).
Repetir o POST com o mesmo CPF/CNPJ antes da confirmação cria uma nova accreditation (não devolve a pendente). Depois do vínculo, retorna 409 already_accredited.
Quando o documento já tem conta no liquidante, a accreditation falha com errorReason=existing_partner_account e mensagem orientando o titular a pedir via suporte a transferência do controle para o seu tenant.
address.neighborhood (ou district) passa a ser obrigatório no POST /v1/accreditations/pf|pj.

v2.29.2 (2026-07-15) - PIX out: timeout de comunicação não emite mais `pix.out.failed`

Corrige falso-negativo: quando a chamada de envio ao parceiro sofria timeout de comunicação (sem resposta HTTP), a API marcava a ordem como FAILED e emitia pix.out.failed — mesmo que o pagamento tivesse sido processado e liquidado no SPI. Um pix.out.completed tardio podia chegar em seguida, gerando dois eventos terminais contraditórios.
Agora o desfecho indeterminado entra na janela de confirmação (poll/webhook do parceiro): se o pagamento saiu, emitimos apenas pix.out.completed; se foi recusado, pix.out.failed com o motivo real; sem confirmação em 5 minutos, pix.out.timeout.
Semântica contratual reforçada na documentação: pix.out.failed é terminal e definitivo (nunca seguido de completed); incerteza é sempre pix.out.timeout.

v2.28.2 (2026-07-10) - Webhook `pix.out.timeout`

PIX out em TIMEOUT agora emite o webhook outbound pix.out.timeout (antes só gravava timeline; o fanout ignorava TIMEOUT).
EventID determinístico pix-out-timeout-{paymentId} — não colide com um pix.out.completed/failed tardio.
Backoffice: opção de assinar pix.out.timeout na config de webhooks.
Docs (cashout / webhooks PT·EN·ZH) alinhadas.

v2.28.1 (2026-07-10) - Devolução PIX: somente estorno total

POST /v1/accounts/{accountId}/pix/out/refund agora rejeita estorno parcial antes de chamar o liquidante. O parceiro atual não aceita valor no endpoint de refund e sempre estornava o PIX inteiro — um amount menor que o original gerava estorno total silencioso.
Se amount < valor original → 400 partial_refund_not_supported.
Se amount > valor original → 400 refund_amount_exceeded.
amount continua obrigatório e deve ser igual ao PIX original.
Documentação (guia de devolução, OpenAPI, erros) atualizada.

v2.27.0 (2026-07-08) - Credenciais somente leitura

Agora é possível ter credenciais de API com escopo limitado. Uma credencial somente leitura (api2/read) acessa apenas endpoints de consulta (GET); qualquer operação de escrita (POST/PUT/PATCH/DELETE) retorna 403 insufficient_scope.
O tenant manager pode criar credenciais somente leitura de forma self-service no painel do backoffice (API Credentials). Credenciais com permissão de escrita continuam sendo provisionadas pela CorpX no onboarding.
Credenciais existentes não mudam: seguem com api2/read api2/write.
Nota: token ausente continua retornando 401; token inválido/expirado agora retorna 403 (antes 401). Consulte o Guia de Autenticação.

v2.26.0 (2026-07-08) - Habilitação por tenant do credenciamento

Os endpoints de abertura de conta (POST /v1/accreditations/pf|pj) agora exigem que o recurso de credenciamento (BaaS) esteja habilitado para o seu tenant. Sem a habilitação, a API responde 403 feature_disabled. Consultas (GET) não são afetadas.
Para habilitar o credenciamento no seu tenant, fale com o time CorpX.

v2.25.0 (2026-07-08) - Abertura de contas self-service com biometria facial

Novos endpoints de credenciamento (accreditation) para abertura de contas PF e PJ direto pela API, com biometria facial. Disponível para integradores BaaS — veja a nova seção Abertura de Contas da documentação.

POST /v1/accreditations/pf — abre conta PF. No fluxo padrão, a CorpX gera um link de captura facial (Unico) para o titular; com a biometria aprovada, a conta abre automaticamente.
POST /v1/accreditations/pj — abre conta PJ. Cada sócio recebe seu próprio link de facial; a abertura ocorre após todos concluírem e a análise da CorpX aprovar (etapa PENDING_REVIEW, obrigatória para PJ).
Biometria própria (BYO) — tenants habilitados podem enviar a facial coletada na sua própria plataforma (Unico, SERPRO, IDWALL, SUMSUB, ClearSale, CAF ou Valid): registre a evidência em POST /v1/accreditations/biometry-evidence e referencie o evidenceId no objeto biometry. O titular confirma em uma página de aceite com a marca do seu tenant.
Acompanhamento — GET /v1/accreditations/pf|pj (filtros document/status), GET /v1/accreditations/{id} e retry de link por pessoa (POST .../persons/{cpf}/retry).
Novos webhooks — accreditation.updated (a cada transição de status), accreditation.biometry.link.created, accreditation.acceptance.link.created, accreditation.active e accreditation.failed. Detalhes em Webhooks de credenciamento.
Criações são idempotentes por tenant + documento: repetir o POST com o mesmo CPF/CNPJ retorna a accreditation existente (200).
OpenAPI e Postman Collection atualizados com os novos endpoints.

v2.24.2 (2026-07-07) - Dados do pagador e recebedor em webhooks e lookup de QR

Enriquecimento retrocompatível dos payloads — nenhum campo foi removido, nenhuma URL mudou.

Webhooks pix.out.completed / pix.out.failed / pix.refund.*: o payload agora inclui os objetos payer (sua conta) e payee (destinatário, com nome e documento resolvidos) para PIX enviados pela API — em todos os modos (chave, QR code e dados bancários). Antes esses objetos só apareciam em transações originadas fora da API.
Lookup de QR code (GET /v1/accounts/{accountId}/pix/qr-code e alias /lookup): quando o QR está PAID, a resposta passa a incluir o objeto payer com nome e documento do pagador, conforme já documentado. Antes o campo podia vir ausente mesmo com o QR pago.
Nenhuma ação necessária: quem já parseia payer/payee passa a recebê-los preenchidos; campos existentes não mudaram.

v2.24.1 (2026-07-07) - Extrato: status por transação não liquidada

Mudança importante para conciliação. O extrato passou a incluir também transações canceladas e em análise, com o status individual de cada registro.

Status por linha do extrato. GET /v1/accounts/{accountId}/statement, GET /v1/accounts/{accountId}/pix/transactions e os exports CSV/PDF refletem o estado de cada registro: COMPLETED (liquidada), PROCESSING (registrada, ainda não liquidada), PENDING_APPROVAL (em análise) e FAILED (cancelada — não movimentou saldo).
Ação recomendada: se sua conciliação soma linhas do extrato, filtre por status = COMPLETED (e REVERSED para estornos). Linhas FAILED e PROCESSING não devem entrar no cálculo de saldo.
O vocabulário de status é o mesmo já documentado — nenhum campo novo foi adicionado.

v2.24.0 (2026-07-07) - PIX out: rejeições imediatas e análise de risco

Mudança comportamental e retrocompatível no fluxo de PIX out — nenhum campo foi adicionado ou removido, nenhuma URL mudou.

Rejeições mais rápidas no fluxo síncrono. Quando o liquidante recusa a transferência de imediato (antifraude ou saldo insuficiente na liquidação), POST /v1/accounts/{accountId}/pix/out agora responde 422 FAILED na hora, com errorCode (partner_rejected ou insufficient_funds) e errorReason preenchidos — antes a resposta era 202 PENDING e a falha só chegava depois, por webhook ou consulta.
Análise de risco sinalizada como PENDING_APPROVAL. Transferências retidas para análise da mesa de risco aparecem com status PENDING_APPROVAL nas consultas de pagamento (antes apareciam como PROCESSING). O desfecho final continua sendo entregue pelos webhooks pix.out.completed / pix.out.failed.
Janela de confirmação estendida durante análise. Pagamentos em PENDING_APPROVAL aguardam o desfecho por até ~30 minutos antes de marcar TIMEOUT (antes: 5 minutos) — menos TIMEOUT falso com confirmação tardia chegando depois.
endToEndId em TIMEOUT. Em casos raros de TIMEOUT sem nenhuma confirmação do liquidante, o endToEndId pode não estar disponível na consulta do pagamento. Guarde o identifier/paymentId para conciliação — eles sempre existem.

v2.22.0 (2026-07-02) - TED com caminho canônico próprio

Reorganização puramente aditiva e retrocompatível — nada quebra.

Novo caminho canônico para status de TED: GET /v1/accounts/{accountId}/ted/{tedId}. O caminho anterior GET /v1/accounts/{accountId}/transfers/ted/{tedId} continua funcionando (mesma resposta), mas passa a ser deprecated e será removido em uma próxima major.
Swagger e Postman reorganizados: os endpoints de TED (POST /ted/out e a consulta de status) ficam agora numa seção própria TED, separada dos endpoints de transferências internas. A seção anteriormente chamada Transfers passa a se chamar Internal Transfers e agrupa apenas as rotas POST /transfers/internal* + GET /transfers/internal/lookup/*.

Migração recomendada: quem usa GET /transfers/ted/{tedId} para consultar status pode passar para GET /ted/{tedId} sem outra mudança — payload é idêntico.

v2.21.0 (2026-07-01) - Normalização de IDs de boleto

O pagamento de boleto passa a expor um id canônico único, alinhado às demais trilhas (PIX, TED). Mudança aditiva e retrocompatível — nenhum campo foi removido.

paymentId em todas as superfícies. POST /v1/accounts/{accountId}/boleto/pay e o status GET /v1/accounts/{accountId}/boleto/payments/{id} agora retornam paymentId (bol_<uuid>) — o mesmo valor que já chega nos webhooks boleto.paid / boleto.failed (como paymentId e transactionId). O campo boletoId continua disponível como alias (mesmo valor).
Status aceita os dois ids. O path do endpoint de status passa a aceitar tanto o paymentId canônico (bol_…) quanto o partnerId (operationReferenceId, legado), e ecoa ambos na resposta. O integrador não precisa mais manter um mapa paymentId ↔ partnerId.

v2.20.1 (2026-06-15) - `fee.charged` e `fee.refunded` para tarifas externas

Webhooks de tarifa agora também são enviados quando a cobrança é emitida fora da API (pelo serviço de cobrança ou pelo próprio liquidante). Antes, esses casos chegavam ao integrador como transfer.internal.out (cobrança) ou transfer.internal.in (estorno), o que contradizia o contrato — agora seguem a tipagem oficial:

fee.charged — emitido quando uma tarifa é debitada da conta do cliente para a contraparte de tarifas (ex.: Corp X Brasil LTDA ou MT Instituição de Pagamento SA). Inclui feeServiceType (PIX / TED / BOLETO / INTERNAL_TRANSFER / MONTHLY / OTHER) e originalRef / transactionRef referenciando a operação que motivou a cobrança.
fee.refunded — emitido quando o liquidante estorna uma tarifa cobrada anteriormente.

Tarifas iniciadas via API (raras hoje) continuam não disparando esses eventos; eles são exclusivos para movimentações originadas externamente.

A estrutura segue o contrato documentado em Webhooks → 9. fee.charged / 9.1. fee.refunded.

v2.20.0 (2026-06-12) - Limites de DICT lookup e cache de 24h

A consulta DICT (GET /v1/accounts/{accountId}/pix/key/{pixKey}) agora respeita os limites configurados na policy do tenant ou da conta:

maxLookupsPerDay — teto absoluto de consultas por dia (calendário em horário de Brasília). 0 ou ausente = ilimitado.
maxLookupRatio — teto relativo: ratio × pix_outs_24h. Exemplo: ratio 3.0 com 100 PIX out nas últimas 24h permite 300 consultas na mesma janela.

Quando ambos estão configurados vale o mais restritivo. Estourar qualquer um deles devolve 429 dict_lookup_limit_exceeded com o contador atual em message.

Além disso, o cache de 24h foi ativado de fato: respostas de uma consulta anterior à mesma chave (até 24h depois) retornam imediatamente com cached: true e não consomem o limite — o objetivo da policy é proteger o DICT contra abuso. Use noCache=true na query para forçar uma consulta fresca.

Os limites podem ser configurados no Backoffice (Policies → DICT Lookup). Tenants sem policy configurada continuam sem limite (comportamento inalterado).

v2.19.1 (2026-06-11) - Correção: webhook `pix.refund.received` indevido em devoluções emitidas

Corrigido: ao emitir uma devolução (POST /v1/accounts/{accountId}/pix/out/refund), o seu endpoint de webhooks podia receber um evento pix.refund.received indevido — como se você tivesse recebido uma devolução de terceiros, quando na verdade foi você quem a emitiu.

Comportamento corrigido:

Devolução emitida por você via API: você recebe apenas a confirmação normal do fluxo de devolução (pix.refund.completed / pix.refund.failed). Nenhum pix.refund.received é gerado.
Devolução emitida fora da API (ex.: canais do liquidante): você recebe pix.refund.completed / pix.refund.failed com external: true.
Devolução recebida de terceiros (contraparte devolveu um PIX que você enviou): pix.refund.received continua sendo enviado normalmente.

v2.19.0 (2026-06-10) - Fim do limite de R$ 15.000 por transação PIX; BigPix descontinuado

O limite de R$ 15.000 por transação PIX foi removido pelo liquidante. POST /v1/accounts/{accountId}/pix/out (e as variantes /async, /bank-account, /qr-code) agora aceitam qualquer valor em uma única transação — sem necessidade de dividir em múltiplos PIX.

Com isso, o BigPix está descontinuado:

POST /v1/accounts/{accountId}/pix/out/bigpix
POST /v1/accounts/{accountId}/pix/out/bank-account/bigpix
GET /v1/accounts/{accountId}/pix/out/bigpix/{batchId}

Esses endpoints continuam funcionais por retrocompatibilidade, mas as respostas agora incluem o header Deprecation: true. Recomendamos migrar para POST /pix/out (ou /pix/out/bank-account), que tem o mesmo shape de request — basta enviar o valor total no campo amount. A data de remoção definitiva será anunciada neste changelog com antecedência.

Os limites operacionais da sua conta (diário, noturno, por contraparte) continuam valendo normalmente — consulte GET /v1/accounts/{accountId}/limits.

v2.18.3 (2026-06-09) - Webhooks para transferências internas externas

Transferências internas entre contas do mesmo banco (MT Bank) originadas fora da API — como pelo aplicativo móvel ou console do parceiro — agora disparam webhooks transfer.internal.in (para a conta que recebeu) ou transfer.internal.out (para a conta que enviou).

Isso complementa o comportamento existente: transferências internas iniciadas via POST /v1/accounts/{accountId}/transfers/internal já disparavam webhooks para ambas as pontas. Agora, movimentações que você não iniciou via API também notificam seu endpoint de webhooks, com o campo external: true no payload indicando que a origem foi externa.

v2.18.2 (2026-06-07) - Erro de devolução (refund) mais preciso

Devolução de PIX (POST /v1/accounts/{accountId}/pix/out/refund): quando a transação original não permite devolução (não está Confirmado — já devolvida/revertida, rejeitada ou ainda processando), a recusa agora volta com errorCode: conflict e o motivo do liquidante em errorReason/message (ex.: Transação com status diferente de 'Confirmado'.).

Antes esse caso voltava errorCode: invalid_payload com o errorReason contendo o JSON bruto do parceiro. Agora o código reflete corretamente um conflito de estado (não um payload inválido) e o motivo vem limpo.

Além disso, a consulta exata do extrato (por endToEndId/identifier em GET /v1/accounts/{accountId}/statement) passou a consultar o liquidante diretamente e pode incluir os campos opcionais initiation, errorMessage e fee no item, além de payer/payee/counterParty completos.

v2.18.1 (2026-06-07) - Saldo é somente leitura (sem bloqueio do nosso lado)

Esclarecimento de contrato: a API não trata bloqueio de saldo. O GET /v1/accounts/{accountId}/balance apenas exibe o valor bloqueado pelo liquidante no campo locked (espelho do bloqueio da MT). Não existe endpoint de lock/unlock de saldo nem "hold local".

A resposta de saldo não inclui o campo locks (lista de bloqueios locais) — esse campo nunca foi populado e foi removido da especificação. Os campos total, locked, available, currency e updatedAt permanecem inalterados.

v2.18.0 (2026-06-06) - Saldos diários, contraparte enriquecida e novos filtros no extrato

Novo endpoint GET /v1/accounts/{accountId}/daily-balance: retorna a série de saldos diários da conta — saldos de abertura (total / bloqueado / disponível no início de cada dia) e os fluxos consolidados do dia (PIX entrada/saída, TED entrada/saída, transferências internas, pagamentos de boleto, mint/burn de stablecoin e tarifas). As datas são dias-calendário em horário de Brasília (BRT). Janela máxima de 30 dias. Só são retornados fechamentos a partir de 04/06/2026 (dados do liquidante anteriores a essa data eram inconsistentes e ficam omitidos) — a resposta inclui cutoffDate e timezone.

Extrato (GET /v1/accounts/{accountId}/statement) — campos novos (aditivos, retrocompatíveis):

transactionType: código C (crédito/entrada) ou D (débito/saída), espelhando direction.
counterParty agora inclui os dados bancários da contraparte quando o liquidante informa: bankName, bankIspb, bankCode, branch, account, accountType, pixKey (antes só name e document).

Extrato — filtragem agora é 100% server-side:

O filtro operation (PIX, TED, BOLETO, INTERNAL_TRANSFER) é aplicado no liquidante, com totalElements/totalPages exatos. Combine com order (asc/desc) e startDate/endDate.
Os filtros status e operation=FEE foram removidos: eram aplicados apenas sobre a página corrente (pós-paginação), o que gerava contagens inconsistentes. O campo filteredCount da resposta também foi removido. Para filtrar por status ou tarifa, processe os items retornados no seu lado.

v2.17.0 (2026-06-05) - Limite do `identifier` ampliado para 38 caracteres

O campo identifier enviado pelo integrador em PIX out, QR codes (estático/dinâmico) e transferências internas passa a aceitar até 38 caracteres (antes: 32). O charset ([A-Za-z0-9._-]) e o prefixo reservado fee- permanecem iguais.

Mudança 100% retrocompatível: identifiers existentes com até 32 caracteres continuam válidos sem nenhuma alteração no código do integrador. Apenas o teto foi relaxado.

Motivação: alinhar o limite de PIX individual com o do BigPix (que já era 38 chars no identifier base do batch). Integradores que usam ambos os fluxos não precisam mais de schemes diferentes de geração de id entre eles.

v2.16.0 (2026-06-02) - Extrato legacy (pré-cutover)

Novo endpoint GET /v1/accounts/{accountId}/statement/legacy para consultar o histórico importado do core anterior (Finaya/Stark), lido de legacy_transactions.

Contrato: mesmo shape de GET /v1/accounts/{accountId}/statement (page, size, startDate, endDate, status, operation). Resposta com source: legacy, header X-Source: legacy. Cada item inclui ispb (30306294 Finaya, 20018183 Stark) e source: legacy.

Sem alteração no extrato live (GET .../statement) — continua só MT Bank real-time.

Visão unificada legacy + live em bulk: export CSV assíncrono (POST /v1/accounts/{accountId}/exports).

v2.15.0 (2026-05-30) - Export de extrato reativado

Export CSV de extrato reativado no modelo live (MT Bank) + histórico legacy (legacy_transactions).

Endpoints:

POST /v1/accounts/{accountId}/exports — cria job assíncrono (202)
GET /v1/accounts/{accountId}/exports — lista jobs
GET /v1/accounts/{accountId}/exports/{exportId}/download — URL presigned

CSV: colunas alinhadas ao extrato, com ispb para distinguir Finaya/Stark (legacy) de MT Bank (live). Sem coluna de saldo após (balance). Períodos longos são fatiados em janelas de 31 dias na consulta live.

v2.14.0 (2026-05-30) - Consulta de dados bancários da conta

Novo endpoint GET /v1/accounts/{accountId}/bank-account para consultar código do banco (COMPE), agência e número da conta credenciada.

Resposta (200):

bankCode, bankIspb, bankName, branch, accountNumber
holderDocument, holderName, accountId, status

Útil para exibir instruções de depósito ou reconciliar transferências sem depender de chaves PIX. Contas ainda em credenciamento retornam 422 com mensagem clara.

v2.13.0 (2026-05-25) - Decode de QR Code mais rico

O endpoint POST /v1/accounts/{accountId}/pix/out/qr-code/decode agora expõe todos os dados que o liquidante já retornava no capture do QR — antes a maior parte ficava só nos logs internos. A mudança é 100% retrocompatível: todos os campos existentes continuam presentes; apenas novos campos foram adicionados.

Campos novos no response (opcionais; presentes quando o liquidante envia):

originalAmount — valor de face do QR antes de descontos/juros/multa (em dynamic-due-date pode diferir de amount).
qrCodeType (static | dynamic-immediate | dynamic-due-date) e qrCodeTypeId (numérico) — promovidos a nível top-level (antes só existiam embaixo de Extra).
allowChange — agora realmente populado com o valor do liquidante (AllowPayerChangeValue) em dynamic-immediate; antes estava documentado mas nunca era preenchido.
payeeTradeName — nome fantasia da PJ (típico em dynamic-due-date).
bankIspb / bankBranch / bankAccount / accountType — dados bancários do recebedor. accountType é canonicalizado para CHECKING | SAVINGS | PAYMENT | SALARY (ou upper snake-case para variantes ainda não vistas).
discount, deduction, interest, penalty — componentes do valor em dynamic-due-date. Relação: amount = originalAmount - discount - deduction + interest + penalty. Antes só discount constava na doc (sempre 0).
dueDate e paymentDeadline — promovidos a nível top-level (antes ficavam em Extra; permanecem em Extra por retrocompat).

Compatibilidade: key, amount, payeeName, payeeDocument, identifier, decodeId, description continuam com o mesmo nome e shape. Integrações antigas seguem funcionando sem mudança.

v2.12.1 (2026-05-24) - PIX status `PENDING_APPROVAL`

Novo status canônico retornado pelos endpoints PIX (GET /v1/accounts/{accountId}/pix/payments/lookup, GET /v1/accounts/{accountId}/payments/{paymentId}, extrato e webhooks de envelope):

PENDING_APPROVAL — o liquidante aceitou o pedido de PIX OUT mas está retendo para aprovação interna (multi-alçada, 2FA, esteira anti-fraude). Ainda não existe endToEndId, e o dinheiro não saiu. Em algum momento o liquidante libera (vira PENDING → COMPLETED) ou recusa (vira FAILED).

Por que o status novo: antes, esse cenário era propagado como o valor cru do parceiro (AWAITING-AUTHORIZATION), que vazava pela API pública. A partir desta versão nunca propagamos valor cru de parceiro — todo status é canonicalizado. Status fora do vocabulário conhecido vira UNKNOWN + warning estruturado no nosso lado para que adicionemos o mapeamento na próxima release.

Sem impacto para integrações com PIX OUT comum (fluxo já passa por PROCESSING → COMPLETED/FAILED). Integrações que monitoram status intermediários devem aceitar PENDING_APPROVAL como não-terminal (continuar polling ou aguardar webhook subsequente).

Webhooks pix.out.completed / pix.out.failed continuam só disparando em estados terminais — PENDING_APPROVAL não emite webhook outbound.

v2.12.0 (2026-05-23) - TED disponível (envio + recebimento)

Novidade major: TED (Transferência Eletrônica Disponível BACEN) agora é um produto público da API. Cobre envio interbancário, consulta de status assíncrona e webhooks de recebimento. Banco liquidante: MT Instituição de Pagamentos (Compe 681 / ISPB 50871921). Ver Guia TED.

Endpoints novos

POST /v1/accounts/{accountId}/ted/out — envia TED (assíncrono, 202)
GET /v1/accounts/{accountId}/transfers/ted/{tedId} — consulta status (PROCESSING → COMPLETED | FAILED)

Webhooks novos

ted.out.requested — TED registrada no liquidante (status inicial)
ted.out.confirmed — liquidação confirmada (terminal — sucesso)
ted.out.failed — rejeição/expiração/timeout 48h (terminal — falha)
ted.in.received — TED recebida na sua conta

Janela e tempos

Dias úteis 06:30–17:00 → liquidação no mesmo dia útil (~30min após envio)
Fora da janela → agendada para D+1 útil; status fica PROCESSING até liquidar
Servidor faz polling defensivo a cada 1 minuto por até 48 horas — garantia de convergência mesmo se webhook do liquidante falhar

Deprecação

ted.payment (catálogo legado v1) vira alias deprecated de ted.out.confirmed. Ambos são disparados juntos durante o ciclo de vida da v2.x; ted.payment será removido na v3.0 (data a ser anunciada).

Novos integradores: assinar apenas ted.out.confirmed
Integradores legados: podem manter ted.payment até v3.0; migração é desassinar + assinar ted.out.confirmed (payloads idênticos)

v2.11.1 (2026-05-22) - Correção: webhook duplicado em tenants com múltiplas subscriptions

Bug fix de impacto direto para integradores que têm mais de uma subscription ativa para o mesmo eventType no mesmo tenant.

Em versões anteriores, cada subscription que casava o evento gerava um POST separado ao egress (Hookdeck). Como o filtro Hookdeck é por tenantId + type no corpo, todos esses POSTs entregavam a TODAS as destinations, multiplicando as entregas: tenant com N subscriptions ao mesmo evento recebia N² entregas ao invés de N.

A partir desta versão, cada evento gera 1 único POST ao egress; o Hookdeck faz o fanout para as N destinations (1 entrega por subscription, sem duplicação).

Não há mudança de payload ou contrato — apenas correção da quantidade de entregas. Se você implementou deduplicação client-side pelo id do envelope, pode mantê-la (ainda é boa prática).

v2.11.0 (2026-05-22) - Envelope de webhook alinhado ao formato v1

O payload dos webhooks de egress (entregues à URL cadastrada por POST /v1/webhooks) volta a seguir o mesmo envelope documentado na v1. Quem migrou v1 → v2 sem mudar o parser do webhook agora recebe os campos exatamente onde esperava.

Envelope (todos os eventos):

Campo	Antes (v2.10)	Agora (v2.11)
`schemaVersion`	ausente	`"1.0"`
`environment`	ausente	`"production"` \| `"sandbox"`
`accountId` (raiz)	apenas em `data.accountId`	adicionado na raiz (continua em `data.accountId`)
`tenantId` (raiz)	já existia	mantido

Campos no data por evento (ajustes para casar com a v1):

pix.in.completed: endToEndId renomeado para endToEnd; adicionado receivedAt.
pix.out.completed / pix.out.failed: status agora é "SUCCESS" / "FAILED" (antes vinha "COMPLETED"); adicionado key: { type, key } quando o PIX foi por chave; adicionado completedAt; adicionado alias error (= errorReason) em falhas.
pix.refund.received: refundEndToEndId → refundEndToEnd; originalEndToEndId → originalEndToEnd; adicionado receivedAt.
qrcode.paid: endToEndId → endToEnd; paidAmount → amount; payerName/payerDocument agrupados em payer: { name, document }; adicionado qrcodeId (= txid), type (static | dynamic), receivedAt, status: "SUCCESS".
qrcode.cancelled: adicionado status: "CANCELLED" e type.
qrcode.expired: adicionado status: "EXPIRED" e type.
pix.med.opened / pix.med.updated: nomes corrigidos para pix.med.* (antes o backend emitia med.opened / med.decided, que não existiam no catálogo público — efetivamente os integradores não recebiam estes eventos). originalEndToEndId → originalEndToEnd; adicionado status (OPEN | PENDING_DECISION | ACCEPTED | REJECTED | CANCELED).
transfer.internal.in / transfer.internal.out: endToEndId → endToEnd.
boleto.paid / boleto.failed: status agora é "SUCCESS" / "FAILED"; adicionado alias error em falhas.

Removido: o campo currency não é mais emitido nem documentado — todos os valores monetários são em BRL por contrato e usam ponto decimal (150.50). A coluna currency nunca chegou a entrar em produção da v2 para a maioria dos eventos; remoção fecha o último gap.

Compatibilidade

Aliases mantidos (lidos e escritos): nenhum dos nomes antigos é mais emitido. Se você consumia data.endToEndId em PIX in ou data.paidAmount em QR pago, precisa renomear para data.endToEnd e data.amount. Verifique os exemplos em Webhooks.

v2.10.0 (2026-05-22) - Vocabulário de refund alinhado ao banco parceiro

POST /v1/accounts/{accountId}/pix/out/refund (e POST /pix/out com mode=REFUND) agora aceita um conjunto fechado de slugs em kebab-case no campo reason. Os valores antigos (USER_REQUESTED, FRAUD, BANK_ERROR, CASHIER_ERROR, CUSTOMER_REQUEST) não são mais aceitos — payloads com esses valores recebem HTTP 400 com mensagem clara listando os slugs válidos.

Os slugs aceitos são repassados literalmente ao banco parceiro (MT Bank), sem tradução intermediária:

Slug	Quando usar
`user-requested`	Cliente final solicitou a devolução
`transaction-error`	Erro genérico na transação
`unauthorized-transaction`	Transação não autorizada
`fraud`	Fraude comprovada/em investigação
`trade-disagreement`	Desacordo comercial
`withdrawal-purchase`	PIX Saque/Troco
`contractual-divergence`	Divergência contratual
`operational-error`	Erro operacional/processamento
`duplicate-payment`	Pagamento duplicado

Motivo da mudança: o endpoint v2 estava devolvendo erro 422 em todos os refunds porque o vocabulário antigo não casava com o aceito pelo banco parceiro. Esta versão alinha API pública e parceiro 1:1, evitando mapeamentos opacos.

v2.9.0 (2026-05-21) - Documento da contraparte no extrato

Os itens do extrato (GET /v1/accounts/{accountId}/statement) agora incluem o documento (CPF/CNPJ) da contraparte além do nome:

recipientName: nome da contraparte (já existente).
recipientDocument: novo campo — CPF (11 dígitos) ou CNPJ (14 dígitos) da contraparte, sem máscara (digits-only).
counterParty: novo objeto agregando { name, document }. Omitido quando ambos os campos estão vazios.

Para transações com direction: "IN", a contraparte é o pagador; para direction: "OUT", é o destinatário. Campos retrocompatíveis — integradores que não precisam do documento não precisam ajustar nada.

v2.0 (2026-05-21) - Nova plataforma CorpX

A v2 é uma reescrita completa da plataforma sobre uma infraestrutura mais rápida e previsível, com integração direta ao novo liquidante. Em geral retrocompatível com a v1.

Guia de migração

Tudo o que você precisa para migrar está em um documento só:

Guia de migração rápida (2 min)
Referência completa (auditoria endpoint-por-endpoint)

Auth

Nova base URL: https://tenant.api.corpx.com/v1 (era https://api.corpxapi.com/v1)
Novo Token URL: https://auth.api.corpx.com/oauth2/token
Novos client_id + client_secret por integrador (entregues por canal seguro)
Scopes: api/full → api2/read api2/write
Idempotency-Key virou opcional (auto-gerado se ausente)
X-Tenant-Id é obrigatório em todas as requisições /v1/* (exceto GET /v1/me e health); deve coincidir com o tenant da conta quando accountId está no path

Statement consolidado em um único endpoint

GET /v1/accounts/{accountId}/statement é agora sempre live — consulta o liquidante em tempo real (sem cache local).
Os endpoints derivados que liam do mesmo cache (/pix/transactions, /pix/payments, /payments alias) também passam a ser live.
A API v1 e o backoffice anteriores continuam no ar em modo somente-leitura por 30 dias após o cutover para consulta histórica.
Endpoints /transactions/real-statement, /transactions/legacy-statement e /payments/{id}/legacy não existem na v2 — use /statement (atual) ou a v1 read-only (histórico).

Endpoints deprecated (ainda funcionam até 2026-11-21)

4 paths que existiam na v1 e ficaram fora da versão canônica da v2 voltam como aliases deprecated. Continuam respondendo normalmente, mas anexam 3 headers de aviso na resposta:

Deprecation: true
Sunset: Sat, 21 Nov 2026 00:00:00 GMT
Link: </v1/accounts/.../novo-caminho>; rel="successor-version"

Esses headers seguem RFC 8594 (Deprecation) e RFC 9745 (Sunset). Sunset previsto: 2026-11-21 — após essa data passam a retornar 410 Gone. Não aparecem mais no OpenAPI nem na Postman collection.

GET /v1/accounts/{id}/pix/payments/{paymentId} → use /pix/payments/lookup?identifier=
GET /v1/accounts/{id}/payments/{paymentId} (alias sem /pix/) → use /pix/payments/lookup?identifier=
GET /v1/accounts/{id}/pix/qr-code (sem /lookup) → use /pix/qr-code/lookup?identifier=
POST /v1/accounts/{id}/pix/out/qrcode (sem hífen) → use /pix/out/qr-code

Endpoints removidos (retornam 404 na v2)

POST /v1/webhooks/replay → sem substituto
GET /v1/integrator/webhooks → use GET /v1/webhooks
GET /v1/integrator/webhooks/{id}/deliveries → sem substituto
POST /v1/integrator/events/replay + /batch → sem substituto
POST .../pix/med/{medId}/send + /response → use /decide + /answer

GET /v1/health continua existindo na v2 (ganhou alias adicional GET /health para health checks externos).

Endpoints novos

GET /v1/me (debug do client_id autenticado)
GET /v1/transactions/{id}/timeline (sem accountId no path)
GET /v1/accounts/{id}/pix/out/bigpix/{batchId} (status agregado de lote BigPix)
GET /health (alias do /v1/health sem o prefixo)
Boleto family (POST .../boleto/preview|pay, GET .../boleto/payments/{id}) — era 503 na v1, agora ativo

Mudanças de comportamento (mesmo path, novo shape ou semântica)

Statement e endpoints derivados: cache → live; sem tariff_ref derivado; header X-Source: live; janela máxima por consulta 31 dias.
Internal transfer by-bank-account: aceita holderDocument + holderName opcionais (não breaking).
Locked balance unlock: v2 só valida lockId; campos extras são ignorados (não breaking).
Campo fee no objeto de transação removido temporariamente — conciliação manual via identifier=fee-{slug}-{operationReferenceId} no extrato. Volta sem mudança de payload em release futura.

MED e webhooks temporariamente suspensos

Endpoints /v1/accounts/{id}/pix/med/* retornam HTTP 503 durante a migração. Disputas em aberto seguem o ciclo natural do BACEN — apenas a integração via API está pausada.
Webhooks suspensos: fee.*, pix.med.*, edi.*. Subscriptions a esses eventos podem permanecer ativas — quando voltarem, retomam automaticamente. Tarifas seguem aparecendo no extrato como linhas independentes (com identifier=fee-{slug}-{ref}).

Compat (sem mudança no seu código)

BigPix (POST .../pix/out/bigpix e .../bank-account/bigpix): body continua single ({amount, key, ...}); chunking permanece server-side, igual à v1.
PIX out variants (/pix/out/async, /bank-account/async, /bank-account/bigpix): preservados.
/v1/accounts/{accountId}/transfers/internal (todos os 3 modos): path e body preservados.
/v1/accounts/{id}/pix/qr-code/static body: value continua como na v1.
/v1/accounts/{id}/pix/out/qr-code/decode: path preservado.
/v1/accounts/{id}/pix/keys (GET + POST + DELETE): mantidos.
/v1/accounts/{id}/pix/key/{pixKey} (DICT lookup): mantido.

Suporte

Contato: api@corpx.com durante o cutover do tenant — resposta em até 1h em horário comercial.

v1.30.3 (2026-04-30) - Eliminação de webhooks duplicados (`pix.refund.completed`, `pix.out.failed`, `qrcode.paid`)

Correções

Webhooks duplicados removidos: a infraestrutura emitia, em alguns cenários, dois webhooks para o mesmo evento — um seguindo o formato documentado e outro com um formato legado nunca descrito na documentação. O comportamento foi corrigido: agora cada evento gera exatamente uma notificação, sempre no formato documentado.

Os eventos afetados eram:
- pix.refund.completed (gerado quando uma devolução é concluída)
- pix.out.failed (gerado quando um PIX OUT falha)
- qrcode.paid (gerado quando um QR Code é pago)
O formato legado nunca esteve presente em docs/webhooks — era uma emissão paralela de uma rotina interna que escapou da documentação. Integrações que dependiam apenas dos campos documentados não percebem nenhuma diferença além da ausência da duplicata.
Campo data.status em pix.refund.completed: agora retorna sempre SUCCESS (alinhado à tabela oficial de status). Antes, em alguns casos, vinha REFUNDED por contaminação com o status da transação original.

Diferenças que somem (apenas para integrações que estavam acopladas ao formato legado, não documentado)

Campo / formato (legado)	Substituído por (formato documentado)
`id: refund_completed_{paymentId}_{ts}`	`id` em formato hash (sha256)
`id: pix_out_failed_{paymentId}_{ts}`	`id` em formato hash (sha256)
`id: qr_paid_{txid}_{ts}`	`id` em formato hash (sha256)
`data.status: COMPLETED` (em `pix.refund.completed`)	`data.status: SUCCESS`
`data.status: REFUNDED` (em `pix.refund.completed`)	`data.status: SUCCESS`
`data.refundId` (em `pix.refund.completed`)	use `data.transactionId` (já documentado)
`data.failedAt` (em `pix.out.failed`)	use `occurredAt` no envelope
`data.paymentId` (em `pix.out.failed`)	use `data.transactionId` (já documentado)
`payer.account` / `payee.account`	`payer.accountNumber` / `payee.accountNumber`

Se sua integração consumia algum desses campos exclusivos do formato legado, ajuste-a para usar os campos documentados antes de adotar essa versão.

Recomendação para deduplicação

Use sempre uma chave forte do payload para deduplicar webhooks no seu lado:

Para pix.refund.completed: data.refundEndToEnd (D-code BACEN, único globalmente).
Para pix.out.failed: data.endToEnd (E-code BACEN) ou data.identifier.
Para qrcode.paid: data.endToEnd ou data.qrcodeId.

Esses campos são únicos por transação e estão presentes em todos os eventos.

v1.30.2 (2026-04-30) - Padronização de timestamps em UTC nos webhooks

Correções

Datas dentro de data agora vêm sempre em UTC com sufixo Z em todos os webhooks. Anteriormente, alguns campos (receivedAt, completedAt, initiatedAt, chargedAt, openedAt) eram repassados sem indicador de fuso horário, o que levava parsers ISO 8601 rigorosos a interpretarem como horário local da máquina e gerava diferenças de até 3 horas em ambientes BRT.
Padrão consolidado e documentado em Webhooks → Formato de datas e horários.
A documentação já indicava Z (UTC) nos exemplos; agora todos os payloads emitidos respeitam o padrão.

v1.30.1 (2026-04-29) - Webhook `qrcode.paid` mantido (não será descontinuado)

Reversão de descontinuação

qrcode.paid segue suportado oficialmente. Avisos de descontinuação que apareciam no Guia de Webhooks (em PT, EN e ZH) foram removidos. O evento continua válido e estável; nenhuma migração é necessária.
O evento equivalente pix.in.completed com method: QR_CODE_DYNAMIC ou QR_CODE_STATIC permanece disponível como alternativa (e continua sendo disparado em paralelo) — escolha a que melhor se encaixa na sua integração.

v1.30.0 (2026-04-23) - Correções em transferências internas (mapeamento de erro + identifier no webhook)

Correções

Mapeamento de erro account_disabled (TX00012) do parceiro bancário: quando a conta de origem está desabilitada no parceiro bancário, a API agora retorna HTTP 422 com errorCode: partner_account_disabled. Antes, esse caso era mapeado para HTTP 502 (Bad Gateway), o que enganava o integrador a tratar como falha de infraestrutura em vez de regra de negócio. A mudança afeta os três endpoints de transferência interna (/transfers/internal, /transfers/internal/by-document, /transfers/internal/by-bank-account).
Classificação unificada de erros do parceiro bancário: erros HTTP do core bancário (usado em transferências internas e leituras de conta) agora passam pelo mesmo classificador já usado nos demais endpoints. Códigos específicos como insufficient_balance, daily_limit_exceeded, account_disabled retornam 422 em vez de 502.

Melhorias

identifier e description agora voltam no webhook transfer.internal.out: o identificador único e a descrição informados pelo integrador no POST /transfers/internal* passam a ser propagados para o webhook enviado à conta pagadora. Permite fechar a reconciliação de transferências internas sem consultar o extrato.
Descrição customizada do pagador substitui o texto padrão Transferência Interna no extrato (GET /statement) quando informada na requisição.
coreId agora vem em todos os webhooks de lançamento: o UUID da linha no core bancário (mesmo valor retornado no campo coreId do extrato) é propagado em pix.in.completed, pix.out.completed, pix.out.failed, pix.refund.*, qrcode.paid, transfer.internal.*, fee.charged e fee.refunded. Permite reconciliar webhook ↔ extrato ↔ exports do parceiro por uma chave única e estável.
status padronizado em todos os webhooks de lançamento: o campo data.status passa a ser garantido em todos os eventos de PIX, QR, transferência interna, refund e tarifa. Vocabulário padronizado: SUCCESS (operação concluída), FAILED (operação falhou, com data.error), REVERSED (lançamento previamente concluído foi revertido). Eventos de MED (pix.med.*) mantêm seu vocabulário próprio (OPEN, PENDING_DECISION, ACCEPTED, REJECTED, CANCELED). Ver tabela completa em docs/webhooks.

Novos `errorCode` retornados

Código	HTTP	Quando acontece
`partner_account_disabled`	422	A conta de origem está desabilitada no parceiro bancário (precisa de reativação)

v1.29.0 (2026-04-18) - Consulta de destinatário de transferência interna por documento

Novos recursos

Consulta prévia de destinatário para transferência interna: Novo endpoint GET /v1/accounts/{accountId}/transfers/internal/lookup/{document} permite consultar o nome do titular antes de executar uma transferência interna por CPF/CNPJ. Útil para exibir uma confirmação ao usuário final.
O nome é retornado com máscara de privacidade: o primeiro nome é mantido integral, e cada sobrenome é reduzido à primeira letra seguida de ***. Conectores como "de", "da", "dos" são preservados.
- Exemplo: "JOAO DA SILVA PEREIRA" → "JOAO da S*** P***"
O endpoint retorna também o accountStatus do destinatário no parceiro bancário.

Fluxo recomendado

Cliente informa o CPF/CNPJ do destinatário
Integrador chama GET /transfers/internal/lookup/{document} e exibe o maskedName para confirmação
Usuário confirma
Integrador chama POST /transfers/internal/by-document para executar a transferência

v1.28.0 (2026-04-17) - Remoção de webhooks deprecated

Breaking Changes

Webhooks payment.sent e payment.refunded desativados: Estes eventos foram marcados como deprecated na v1.15.0 (2026-02-20) e agora foram permanentemente desativados.
- payment.sent → use pix.out.completed (inclui campo method e objeto payment)
- payment.refunded → use pix.refund.completed (inclui originalEndToEnd, refundEndToEnd e detalhes das partes)
Se sua integração ainda assina esses eventos, migre imediatamente para os substitutos listados acima.

v1.27.0 (2026-04-14) - PIX Out por dados bancários

Novos recursos

PIX Out por dados bancários: Novos endpoints para transferir PIX usando agência, conta e ISPB do destinatário (sem necessidade de chave PIX):
- POST /v1/accounts/{accountId}/pix/out/bank-account — Transferência síncrona por dados bancários.
- POST /v1/accounts/{accountId}/pix/out/bank-account/async — Transferência assíncrona (enfileirada).
- POST /v1/accounts/{accountId}/pix/out/bank-account/bigpix — Transferência de valores grandes com split automático em chunks.
Os campos obrigatórios são: bankIspb (código ISPB do banco), accountNumber, accountBranch, documentNumber (CPF/CNPJ do beneficiário) e name.
O campo accountType aceita CHECKING_ACCOUNT, SAVINGS_ACCOUNT ou PAYMENT (padrão: CHECKING_ACCOUNT).

Observações

Webhooks, tarifas e reconciliação são os mesmos do PIX Out por chave — as transações aparecem como PIX_OUT no extrato.
O endpoint async usa a mesma fila FIFO do PIX Out por chave — mesma garantia de ordenação e idempotência.
BigPix funciona igual ao existente: split em chunks de R$ 15.000 (configurável por política), tarifa cobrada uma vez por operação.

v1.26.1 (2026-04-13) - Correções de estabilidade

Correções

QR Code estático: Corrigido o valor gerado no QR code estático que, em alguns cenários, era diferente do valor solicitado.
Webhook pix.in.completed: Corrigido cenário em que o campo identifier não era incluído no payload do webhook para pagamentos via QR code, mesmo quando o identificador estava disponível.

v1.26.0 (2026-04-09) - Pagamento de boleto

Novos recursos

Pagamento de boleto: Novos endpoints para consultar e pagar boletos bancários, contas de serviço (concessionárias) e tributos:
- POST /v1/accounts/{accountId}/boleto/preview — Consulta dados de um boleto pelo código de barras ou linha digitável. Retorna beneficiário, banco, valor original, juros, multa, desconto e valor total atualizado.
- POST /v1/accounts/{accountId}/boleto/pay — Efetua o pagamento de um boleto. Retorna paymentId com status PROCESSING.
- GET /v1/accounts/{accountId}/boleto/payments/{paymentId} — Consulta o status de um pagamento de boleto. O status evolui de PROCESSING para COMPLETED ou FAILED.
Novo tipo de transação BOLETO_PAYMENT: Pagamentos de boleto aparecem no extrato como transações de saída (direction: OUT, transactionType: BOLETO_PAYMENT).
Feature flag boleto_payment: A funcionalidade é controlada por feature flag no tenant_configs. Deve ser habilitada pelo admin para cada tenant que deseja utilizar.

Observações

Boletos bancários (47 dígitos), contas de concessionárias (48 dígitos) e tributos são automaticamente classificados pelo tipo (boleto, utility, tax).
O pagamento é assíncrono — após o POST /boleto/pay, o integrador deve fazer polling no GET /boleto/payments/{paymentId} para acompanhar o status.
Cancelamento de boleto e agendamento para data futura serão implementados em versão futura.

v1.25.1 (2026-04-02) - Referência da transação original em fee.charged e melhorias de devoluções

Melhorias

Webhook fee.charged enriquecido: O payload agora inclui os campos originTransactionType (tipo da transação que originou a tarifa, ex: PIX_IN, PIX_OUT) e originTransactionRef (E2E ID da transação original). Também inclui a description completa com detalhes do cálculo.
Webhook pix.in.completed com identifier para QR codes dinâmicos: Corrigido cenário onde o identifier do QR code não era incluído no webhook quando a confirmação do pagamento chegava antes da notificação de cobrança.
Devoluções mais resilientes: Corrigido cenário onde a devolução era processada com sucesso pelo parceiro bancário mas a API retornava erro temporário. A API agora detecta a confirmação via webhook e retorna o D-code corretamente.

v1.25.0 (2026-03-26) - Campo payerDescription, webhooks de tarifas e correções de devoluções

Novos recursos

Campo payerDescription no extrato e webhooks: O endpoint GET /v1/accounts/{accountId}/statement e os webhooks pix.in.completed, pix.out.completed, qrcode.paid e transfer.internal.* agora retornam o campo opcional payerDescription. Ele contém a mensagem que o pagador digitou ao fazer o PIX (quando disponível). O campo description continua com o formato padronizado descritivo ("PIX Recebido - Nome do Pagador").
Webhooks fee.charged e fee.refunded: Tarifas bancárias agora geram webhooks fee.charged (ao serem cobradas) e fee.refunded (ao serem estornadas). Para receber, adicione esses tipos à sua assinatura de webhook.

Melhorias

Webhooks PIX IN mais completos: Os webhooks pix.in.completed agora sempre contêm dados completos: reconciliationId, payerDescription, dados do pagador e chave PIX. Anteriormente, em alguns cenários o webhook podia chegar com dados parciais.

Correções

Webhooks de devolução (PIX refund): Corrigido um cenário onde o webhook pix.refund.completed não era entregue ao integrador quando a confirmação da devolução era recebida logo após a criação.
Webhooks de PIX em transferências internas (CORPX-CORPX): Corrigido o tipo de evento para transferências entre contas CORPX. Antes, o destinatário podia receber pix.out.completed ao invés de pix.in.completed.
reconciliationId em QR codes estáticos: Corrigido cenário onde o reconciliationId não era incluído no webhook pix.in.completed para pagamentos de QR codes estáticos.
Filtro por status no extrato: Corrigido o filtro status no endpoint de extrato que em alguns cenários não retornava resultados corretamente.

v1.24.1 (2026-03-18) - Semântica de erros (redução de 502 genérico)

Melhorias

Padronizamos o retorno de erros originados no parceiro para códigos HTTP semânticos em endpoints de pix/keys, pix/key/{pixKey} (DICT), pix/limits, pix/out/qr-code, pix/out/qr-code/decode, pix/med, transfers/internal, accreditations e accounts/{accountId}/balance.
O formato de erro permanece estável: { "errorCode": "...", "message": "..." }.
OpenAPI e Postman foram atualizados para refletir os novos formatos/status de erro por endpoint.

Mapeamento de erros alterados (de -> para)

Erro / cenário	Antes	Agora
Timeout no Pix Out síncrono (`POST /pix/out`)	`504 Gateway Timeout`	`207 Multi-Status` (`partner_timeout`)
`pix_key_not_found` no Pix Out síncrono (`POST /pix/out`)	`502 Bad Gateway`	`422 Unprocessable Entity`
`partner_error` genérico em falhas de negócio/validação (PIX/Transfers/MED/Accreditations)	`502 Bad Gateway`	`422 Unprocessable Entity`
`pix_key_lookup_failed` (falha DICT/parceiro classificada)	`502 Bad Gateway`	`422 Unprocessable Entity`
`partner_auth_failed` / `partner_signature_rejected`	`502 Bad Gateway`	`503 Service Unavailable`
`partner_internal_error` / `partner_recipient_unavailable`	`502 Bad Gateway`	`503 Service Unavailable`
`partner_timeout` (endpoints com timeout upstream)	`502 Bad Gateway`	`504 Gateway Timeout`
`account_not_found` em fluxos integrados ao parceiro	`502 Bad Gateway`	`404 Not Found`
`pix_key_not_found` no DICT lookup (`GET /pix/key/{pixKey}`)	`502 Bad Gateway`	`404 Not Found`
Fallback não classificado	`502 Bad Gateway`	`502 Bad Gateway` (mantido como fallback)

v1.24.0 (2026-03-18) - Pix Out síncrono: rate limit por conta e timeout 207

Breaking Changes

Mudança de status em timeout no Pix Out síncrono: o endpoint POST /v1/accounts/{accountId}/pix/out agora retorna HTTP 207 (partner_timeout) em timeouts do parceiro, em vez de HTTP 504.
O comportamento esperado permanece: o PIX pode ter sido enviado; confirme no extrato/status do pagamento antes de reenviar.

Melhorias

Rate limit por conta no Pix Out síncrono: aplicado limite por conta (default atual 100 req/min, com possibilidade de customização por policy).
Próximos dias: o default das requisições síncronas será ajustado para 10 req/min.
Quando o limite é excedido, a API retorna 429 rate_limit_exceeded com campos de contexto (currentRateLimit, scope) e orientação para fluxo assíncrono.
Novo endpoint assíncrono de cashout: POST /v1/accounts/{accountId}/pix/out/async agenda o pagamento e retorna 202 imediato com paymentId para rastreio.
BigPix sempre assíncrono: POST /v1/accounts/{accountId}/pix/out/bigpix agora agenda no fluxo assíncrono (mesmo comportamento do endpoint /async), sem execução síncrona.

v1.23.0 (2026-03-17) - Consulta de QR Code PIX (Decode)

Novas funcionalidades

Consulta/decodificação de QR Code PIX: Novo endpoint POST /v1/accounts/{accountId}/pix/out/qr-code/decode permite decodificar um QR Code PIX (string EMV) e visualizar os dados do beneficiário antes de efetuar o pagamento. Retorna: nome, documento, valor, chave PIX, banco e tipo de conta do destinatário. Útil para exibir uma tela de confirmação ao usuário antes de pagar.

v1.22.0 (2026-03-07) - Transferência interna por documento e por agência/conta

Novas funcionalidades

Transferência interna por documento (CPF/CNPJ): Novo endpoint POST /v1/accounts/{accountId}/transfers/internal/by-document permite criar transferências internas identificando a conta de destino pelo CPF ou CNPJ do titular. Funciona para qualquer conta no ecossistema bancário, não apenas contas registradas na API. Campos obrigatórios: document, value, description.
Transferência interna por agência e conta: Novo endpoint POST /v1/accounts/{accountId}/transfers/internal/by-bank-account permite criar transferências internas identificando a conta de destino por agência (branch) e número da conta (accountNumber). Funciona apenas para contas registradas na API (mesmo tenant). Para transferir para contas externas, use o endpoint /by-document.

v1.20.0 (2026-03-01) - Validação de propriedade de conta

Melhorias

Validação reforçada de propriedade de conta: A API agora verifica que o accountId presente na requisição pertence ao tenant autenticado. Integradores que acessam apenas suas próprias contas não são afetados. Essa melhoria reforça a segurança contra acessos indevidos entre contas.

v1.19.1 (2026-02-26) - Melhoria no BigPix

Melhorias

BigPix (POST /v1/accounts/{accountId}/pix/out/bigpix): aprimoramos a robustez do processamento das parcelas para maior consistência em cenários de alto volume.

v1.19.0 (2026-02-26) - Timeline de transação

Novas funcionalidades

Timeline de transação: Novo endpoint GET /v1/accounts/{accountId}/transactions/timeline retorna a linha do tempo de uma transação (por endToEndId ou identifier). Inclui: confirmações BACEN (texto resumido), webhooks enviados ao cliente (com payload completo para "Ver payload completo"), tarifas, estornos e ciclo de vida do QR Code quando aplicável. Exatamente um dos parâmetros de query é obrigatório: endToEndId ou identifier. Nenhuma alteração em endpoints ou formatos existentes.

v1.18.0 (2026-02-24) - Otimizações de performance e tarifas independentes

Melhorias

Tarifas como transações independentes: Tarifas cobradas pela API agora aparecem como linhas separadas no extrato, com link para a transação original. Consultas de QR Code e pagamentos agora incluem detalhes de tarifas (fees, totalFees).
Otimizações de performance: Processamento em lote paralelo para reconciliação, suporte a maior volume de transações simultâneas.
Retry automático de tarifas pendentes: O processo de self-healing agora inclui retry de tarifas que falharam na cobrança inicial.

Correções

Corrigido cálculo de taxas de disputas (MED) que contava transações e disputas em dobro.
Corrigida cobrança de tarifas que podia falhar silenciosamente em cenários de alta concorrência.

v1.17.0 (2026-02-22) - Reconciliação automática e correção de status de transações

Melhorias

Reconciliação automática (Self-Healing): QR Codes expirados são agora marcados automaticamente. QR Codes pagos e pagamentos pendentes são reconciliados periodicamente com o extrato, garantindo consistência mesmo em caso de falhas pontuais de comunicação.
Correção de status de transações: Transações PIX que já atingiram um status final (SUCCESS, FAILED, REVERSED) não podem mais ser sobrescritas por webhooks atrasados, eliminando casos raros onde uma transação concluída poderia temporariamente aparecer como pendente.

v1.16.2 (2026-02-21) - Consultas enriquecidas de QR Code e Pagamentos

Melhorias

Os endpoints de consulta de QR Code (GET /v1/accounts/{accountId}/pix/qr-code/lookup) e pagamento (GET /v1/accounts/{accountId}/pix/payments/lookup, GET /v1/accounts/{accountId}/pix/payments/{paymentId}) agora retornam um objeto transaction enriquecido quando a transação está reconciliada.
O objeto transaction inclui: status detalhado, payer/payee completos, saldo após transação, informações de tarifa cobrada, disputas (MED), violações de política, referências de refund e motivo de erro (quando aplicável).

v1.16.1 (2026-02-21) - Correções de respostas de parceiro

Correções

Corrigido erro HTTP 502 ao deletar chave PIX (DELETE /v1/accounts/{accountId}/pix/keys/{pixKey}). A operação era concluída com sucesso, mas a resposta da API retornava erro incorretamente.
Corrigido erro HTTP 502 ao solicitar devolução/refund (POST /v1/accounts/{accountId}/pix/refund). A devolução era processada com sucesso, mas a resposta da API retornava erro incorretamente.
Melhorias gerais no tratamento de respostas do parceiro para todas as operações PIX.

v1.16.0 (2026-02-20) - Endpoints de Lookup e Paginação de Pagamentos

Novas Funcionalidades

Endpoints de Lookup (busca de item único)

Novo endpoint GET /v1/accounts/{accountId}/pix/qr-code/lookup para busca de QR Code por:
- ?identifier=X -- identificador fornecido na criação
- ?qrcodeId=X -- ID interno do QR Code (txid)
- ?endToEndId=X -- código E2E do BACEN (quando o QR foi pago)
Novo endpoint GET /v1/accounts/{accountId}/pix/payments/lookup para busca de pagamento por:
- ?paymentId=X -- ID do pagamento
- ?identifier=X -- identificador fornecido na criação
- ?endToEndId=X -- código E2E do BACEN
Apenas um parâmetro pode ser enviado por vez em ambos os endpoints.

Paginação na listagem de Pagamentos

O endpoint GET /v1/accounts/{accountId}/payments agora suporta paginação:
- ?page=0&size=50 (padrão: page=0, size=50, máximo: 200)
- Resposta inclui: totalElements, totalPages, page, size, hasNext, hasPrevious

Paginação na listagem de QR Codes

O endpoint GET /v1/accounts/{accountId}/pix/qr-codes agora suporta paginação:
- ?page=0&size=50&status=PAID (padrão: page=0, size=50, máximo: 200)
- Resposta inclui: totalElements, totalPages, page, size, hasNext, hasPrevious

Padronização de rotas

Novo alias POST /v1/accounts/{accountId}/pix/out/qr-code (com hífen, padrão recomendado).

Deprecated

GET /v1/accounts/{accountId}/payments → use /v1/accounts/{accountId}/pix/payments
GET /v1/accounts/{accountId}/payments/{paymentId} → use /v1/accounts/{accountId}/pix/payments/{paymentId}
POST /v1/accounts/{accountId}/pix/out/qrcode (sem hífen) → use /pix/out/qr-code (com hífen)
Rotas antigas continuam funcionando mas serão removidas em versão futura.

v1.15.0 (2026-02-20) - Campo `method` nos webhooks e reconciliacao de refunds

Novas Funcionalidades

Campo `method` nos webhooks PIX

Os webhooks pix.in.completed, pix.out.completed e pix.out.failed agora incluem o campo method no data, indicando a forma de pagamento/recebimento.
PIX IN: PIX_KEY, QR_CODE_STATIC, QR_CODE_DYNAMIC, REFUND_RECEIVED
PIX OUT: PAYMENT, REFUND_PIX_KEY, REFUND_QR_STATIC, REFUND_QR_DYNAMIC

Objetos contextuais nos webhooks

Quando o PIX IN foi recebido via QR Code, o webhook inclui o objeto qrCode com txid, identifier, type e value.
Quando o PIX OUT foi criado via API, o webhook inclui o objeto payment com paymentId, identifier e reconciled.

Reconciliacao de refunds com QR Codes

Refunds de PIX recebidos via QR Code agora atualizam automaticamente o registro do QR Code com os detalhes do refund.
O endpoint de consulta de QR Code (GET /v1/accounts/{accountId}/pix/qr-code) retorna a lista completa de refunds no campo refunds[].

Deprecated

qrcode.paid: use pix.in.completed com method: QR_CODE_DYNAMIC ou QR_CODE_STATIC. Sera removido em versao futura.
payment.sent: use pix.out.completed com method: PAYMENT e objeto payment. Sera removido em versao futura.
payment.refunded: use pix.out.completed com method: REFUND_*. Sera removido em versao futura.

v1.14.0 (2026-01-16) - BigPix: Transferências de alto valor

Novas Funcionalidades

Endpoint BigPix (`POST /v1/accounts/{accountId}/pix/out/bigpix`)

Novo endpoint para transferências PIX acima do limite individual (R$15.000 por padrão).
Divide automaticamente o valor em múltiplas transferências menores, executadas em paralelo.
Cada parcela inclui identificação no formato PIX X/Y - Total R$... - mensagem [id].
Se o campo identifier for fornecido, cada parcela recebe identifier__X/Y.
Resposta consolidada com status FULL (todas ok), PARTIAL (algumas falharam) ou FAILED (nenhuma executou).
Inclui contagem de retries por parcela e detalhes individuais (E2E ID, status, erro).
Tamanho do chunk configurável por tenant via política pixOut.chunkSize.

v1.13.2 (2026-01-16) - Melhorias na entrega de webhooks

Melhorias

Novas assinaturas de webhook passam a ter headers redundantes removidos antes do envio ao destinatário.

v1.13.1 (2026-02-19) - Remoção de qrCodeFormat e Fluxo de Aprovação

Breaking Changes

Campo `qrCodeFormat` removido dos endpoints de QR Code

O campo qrCodeFormat foi removido dos endpoints de criação de QR Code dinâmico e estático.
A API agora sempre retorna o QR Code no formato EMV (copy-and-paste). O formato IMAGE não é mais suportado.
Requisições que ainda enviem qrCodeFormat no body não receberão erro, mas o campo será ignorado.

Novas Funcionalidades

Fluxo de Aprovação de Pagamentos

Quando a política requireApprovalAbove está configurada, pagamentos PIX Out acima do limite agora criam uma intenção de pagamento com status PENDING_APPROVAL em vez de serem rejeitados.
Administradores podem aprovar ou rejeitar pagamentos pendentes via painel de administração.
Ao aprovar, o pagamento é executado automaticamente. Ao rejeitar, o motivo é registrado.

v1.13.0 (2026-02-18) - Disputas (MED), Políticas com Enforcement e Contestação

Novas Funcionalidades

Gestão de Disputas (MED)

Novo sistema de gestão de disputas MED com reconciliação automática de MEDs com transações via E2E ID.
Dados da MED (status, prazo, reclamante, motivo) agora aparecem vinculados à transação no extrato.
Monitoramento de taxa de MED: estatísticas diárias de proporção MED/PIX-In por tenant.
Novos endpoints:
- GET /v1/backoffice/tenants/{tenantId}/med-stats - Estatísticas diárias de MED.
- POST /v1/accounts/{accountId}/pix/med/{medId}/answer - Contestação de MED com resposta e evidências.
- POST /v1/accounts/{accountId}/pix/med/{medId}/evidence/upload-url - Upload de arquivos de evidência.

Enforcement de Políticas PIX In

As regras de PIX In agora são aplicadas em tempo real (anteriormente apenas registravam violações).
Ação AUTO_REFUND agora inicia o estorno automático da transação que violou a política.
Violações de política aparecem no extrato com detalhes da regra, ação e mensagem.

Novas Regras de Política

PIX In: Blacklist de códigos de banco, restrição de mesma titularidade.
PIX Out: Whitelist agora é avaliada antes de blacklist (whitelist anula todas as outras regras).
MED: Auto-bloqueio de saldo para MEDs acima de um valor, limite de taxa MED/PIX-In com ações configuráveis.

Melhorias

Documentação: novo guia de Políticas e Regras com detalhes de todas as regras e ordem de avaliação.
Documentação: novo guia de Disputas (MED) com ciclo de vida, contestação e monitoramento.

v1.12.1 (2026-02-18) - Refund Reason Obrigatório e Correção de Paginação

Novas Funcionalidades

Novo endpoint GET /v1/accounts/{accountId}/pix/key/{pixKey} para consulta DICT com cache de 24h e rate limiting configurável.

Breaking Changes

Campo `reason` agora obrigatório no endpoint de devolução

O endpoint POST /v1/accounts/{accountId}/pix/out/refund agora exige o campo reason com um dos valores: USER_REQUESTED, FRAUD, BANK_ERROR, CASHIER_ERROR, CUSTOMER_REQUEST.
Requisições sem reason ou com valor inválido retornarão HTTP 400.

Melhorias

Header X-API-Version incluído em todas as respostas da API para facilitar debug de versão.

Correções

Corrigido: paginação do extrato ficava em branco a partir da página 11 (mais de 1000 transações).

v1.12.0 (2026-02-18) - Policy Engine

Novas Funcionalidades

Motor de Políticas

Novo sistema de políticas configuráveis por tenant e por conta, com hierarquia (padrão -> tenant -> conta).
Regras disponíveis:
- PIX Out: limite por transação, limite noturno, tipos de pessoa permitidos (PF/PJ), whitelist/blacklist de CPF/CNPJ, horário de operação.
- PIX In: limite de valor, quarentena automática, ação configurável por violação (QUARANTINE, AUTO_REFUND, ALLOW_AND_NOTIFY).
- QR Code: permissões por tipo (dinâmico/estático), limites de valor.
- Chaves PIX: limite de número de chaves por conta.
- Estorno: habilitação e limite de valor.
- Horário de operação: janela de horário permitido com suporte a janelas noturnas.

v1.11.1 (2026-02-15) - Correções no Extrato

Correções

Corrigido: paginação do endpoint de extrato (GET /v1/accounts/{accountId}/statement) não funcionava corretamente. Parâmetros page e size agora retornam a página solicitada.
Corrigido: descrições padronizadas no extrato (ex: "Transferência Pix", "Devolução Pix", "Tarifa Bancária", "Pagamento de QR Code").
Corrigido: ordenação de transações no extrato quando tarifas e transações ocorriam no mesmo instante.

v1.11.0 (2026-02-15) - Tarifas Bancárias no Extrato e Webhook fee.charged

Novas Funcionalidades

Tarifas no Extrato

Tarifas bancárias cobradas por transação agora aparecem no extrato (GET /v1/accounts/{accountId}/statement) com tipo FEE.
Cada tarifa inclui o campo feeServiceType indicando qual operação gerou a cobrança (ex: PIX_OUT, PIX_IN).

Evento de Webhook `fee.charged`

Novo tipo de evento disponível para assinatura: fee.charged.
Enviado em tempo real quando uma tarifa bancária é cobrada na conta.
Payload inclui: amount, currency, feeServiceType, description, chargedAt.

v1.10.0 (2026-02-13) - Reconciliation ID, Suporte a Devoluções via Reversal

Novas Funcionalidades

Reconciliation ID

Todos os webhooks enviados ao integrador (qrcode.paid, pix.in.completed, pix.out.completed, pix.out.failed, pix.refund.completed, pix.refund.failed) agora incluem o campo reconciliationId quando disponível.
O campo reconciliationId também é retornado no endpoint de extrato (GET /v1/accounts/{accountId}/statement), permitindo cruzamento com extratos bancários.

Suporte a Devoluções (PIX Reversal)

A API agora processa devoluções PIX iniciadas pelo destinatário (PIX Reversal). Quando o destinatário de um PIX Out devolve o valor, a transação é registrada automaticamente no extrato e vinculada ao pagamento original.
O status do pagamento original é atualizado para REFUNDED quando o valor total é devolvido.

Correções

Corrigido: webhook qrcode.paid agora inclui dados completos de payer e payee (nome, documento, banco, agência, conta), igual ao pix.in.completed.
Corrigido: valores monetários no extrato sincronizado estavam incorretos (divisão duplicada).

v1.9.0 (2026-02-13) - Lifecycle de Pagamentos, Correções de QR Code e Webhooks

Novas Funcionalidades

Lifecycle Completo de Pagamentos (PIX Out)

Pagamentos (PIX Out) agora possuem ciclo de vida completo com rastreamento de reconciliação.
A resposta do endpoint GET /v1/accounts/{accountId}/payments agora inclui:
- reconciled: indica se o pagamento foi confirmado pelo parceiro bancário.
- reconciledAt: data/hora da confirmação.
- transactionId: vincula o pagamento à transação confirmada no extrato.
Status do pagamento: CREATED → PENDING → COMPLETED (ou FAILED).

Dados Completos de Payer/Payee nos Webhooks

Webhooks pix.in.completed e qrcode.paid agora incluem dados completos do pagador e recebedor (nome, documento, banco, agência, conta, chave PIX).

Validação de Tipos de Evento

Ao criar ou atualizar uma subscription de webhook, os tipos de evento são validados contra a lista oficial. Tipos de evento inválidos ou legados são rejeitados com HTTP 400.

Correções

Corrigido: PIX Out não retornava o campo endToEndId e currency na resposta.
Corrigido: QR Code estático falhava ao ser gerado devido a mudança no formato do parceiro bancário.
Corrigido: campo clientId removido do QR Code estático (não era utilizado).

v1.8.0 (2026-02-11) - Extrato Enriquecido e Correção de Assinatura de Webhook

Novas Funcionalidades

Extrato com Detalhes Completos da Transação

O endpoint de extrato (GET /v1/accounts/{accountId}/statement) agora retorna informações completas de cada transação:
- transactionType: Tipo da transação (PIX_IN, PIX_OUT, QR_CODE_PAYMENT, PIX_REFUND).
- method: Método de pagamento (KEY, STATIC_QR_CODE, DYNAMIC_QR_CODE, MANUAL).
- status: Status atual (SUCCESS, FAILED, PENDING, REFUNDED).
- direction: Direção (IN ou OUT).
- identifier: Identificador fornecido pelo integrador.
- payer / payee: Dados completos do pagador e recebedor (nome, documento, banco, agência, conta, chave PIX).
- originalEndToEnd / refundEndToEndIds: Vinculação entre devoluções e transações originais.
- qrcodeId / qrcodeIdentifier: Reconciliação com QR Codes.

Correções

Corrigido: assinatura HMAC de webhooks não era aplicada corretamente em alguns cenários de atualização de subscription.

v1.7.0 (2026-02-11) - Formato de Webhook, Autenticação Configurável e Assinatura HMAC

Breaking Changes

Formato do Payload de Webhook

O body do webhook agora segue o formato envelope documentado diretamente: { id, type, occurredAt, schemaVersion, environment, accountId, data }.
Campos redundantes foram removidos. O payload agora contém apenas os dados documentados.
Adicionados campos tenantId e eventType no nível raiz para facilitar o roteamento.

Assinatura de Webhook

A assinatura agora é enviada no header X-Signature como base64(HMAC_SHA256(secret, raw_body)).
O formato anterior (hex(HMAC_SHA256(secret, timestamp + "." + body)) com header X-Timestamp) foi descontinuado.
Os headers X-Timestamp, X-Webhook-Event e X-Webhook-ID não são mais enviados.

Novas Funcionalidades

Autenticação Configurável por Subscription

Agora o integrador pode escolher o método de autenticação para cada webhook subscription:
- HMAC (recomendado): Assinatura HMAC-SHA256 no header X-Signature.
- API_KEY: Chave estática em header configurável (padrão: X-API-Key).
- BASIC: Autenticação HTTP Basic (Authorization: Basic ...).
- BEARER: Token Bearer (Authorization: Bearer ...).
- NONE: Sem autenticação (não recomendado para produção).
Configuração feita pelo Painel do Integrador em Webhooks > Editar Subscription.

Melhorias

Documentação de webhooks completamente reescrita com exemplos de verificação de assinatura em Node.js, Python e Go.
Documentação traduzida para Português (locale principal).

Correções

Corrigido: em alguns casos a autenticação configurada para webhooks não estava sendo aplicada corretamente na entrega.

v1.6.0 (2026-02-06) - Padronização de Moeda, Sincronização de Extrato e Validação de Valores

Novas Funcionalidades

Melhorias

Padronização de Moeda

Todos os valores monetários na API agora estão claramente documentados como BRL (REAIS) com no máximo 2 casas decimais (precisão de centavos).
Exemplo: 150.75 representa R$150,75.
Valores com mais de 2 casas decimais agora são rejeitados com HTTP 400 e uma mensagem de erro clara.
Atualizadas todas as descrições de campos OpenAPI com o padrão BRL.
Corrigida a criação de QR Code Estático para aceitar valores em REAIS (anteriormente exigia centavos).

Detalhes Aprimorados de Transação

Adicionado campo transactionType nas respostas de transação (PIX_IN, PIX_OUT, QR_CODE_PAYMENT, PIX_REFUND).
Adicionado campo pixKey nos detalhes de pagador/recebedor.
Corrigida a classificação de QR Code Estático/Dinâmico no extrato.

v1.5.0 (2026-02-05) - Padronização de URLs, API de Pagamentos e Correção de QR Code

Breaking Changes

Padronização de URLs

Todos os endpoints que anteriormente usavam accountId como parâmetro de query agora usam como parâmetro de path sob /v1/accounts/{accountId}/.... Isso fornece padrões de URL RESTful consistentes em toda a API.

Guia de migração:

URL Antiga	URL Nova
`GET /v1/pix/transactions?accountId=X`	`GET /v1/accounts/{accountId}/pix/transactions`
`GET /v1/payments?accountId=X`	`GET /v1/accounts/{accountId}/payments`
`GET /v1/payments/{id}?accountId=X`	`GET /v1/accounts/{accountId}/payments/{id}`
`GET /v1/pix/qr-codes?accountId=X`	`GET /v1/accounts/{accountId}/pix/qr-codes`
`GET /v1/pix/qr-codes/stats?accountId=X`	`GET /v1/accounts/{accountId}/pix/qr-codes/stats`
`POST /v1/pix/qr-code/accounts/{id}/dynamic`	`POST /v1/accounts/{accountId}/pix/qr-code/dynamic`
`POST /v1/pix/qr-code/accounts/{id}/static`	`POST /v1/accounts/{accountId}/pix/qr-code/static`
`GET /v1/pix/qr-code/accounts/{id}`	`GET /v1/accounts/{accountId}/pix/qr-code`
`DELETE /v1/pix/qr-code/accounts/{id}`	`DELETE /v1/accounts/{accountId}/pix/qr-code`
`GET /v1/pix/keys/accounts/{id}`	`GET /v1/accounts/{accountId}/pix/keys`
`POST /v1/pix/keys/accounts/{id}`	`POST /v1/accounts/{accountId}/pix/keys`
`DELETE /v1/pix/keys/{key}/accounts/{id}`	`DELETE /v1/accounts/{accountId}/pix/keys/{key}`
`GET /v1/pix/med`	`GET /v1/accounts/{accountId}/pix/med`
`POST /v1/pix/med/{id}/response`	`POST /v1/accounts/{accountId}/pix/med/{id}/response`

Nota: As URLs legadas continuam funcionando para compatibilidade retroativa, mas estão depreciadas e serão removidas em uma versão futura.

Novas Funcionalidades

API de Pagamentos

GET /v1/accounts/{accountId}/payments: Lista todas as intenções de pagamento PIX Out.
GET /v1/accounts/{accountId}/payments/{paymentId}: Consulta detalhes de um pagamento.

Correções de Bugs

Conciliação de QR Code

Corrigida uma race condition onde pagamentos de QR code não eram vinculados às suas transações quando o webhook de cobrança chegava antes do webhook PIX.

v1.4.0 (2026-01-16) - Padronização de Tipos de Evento de Webhook e Documentação

Novas Funcionalidades

Melhorias nos Tipos de Evento de Webhook

Novo evento pix.med.updated: Notificação quando o status de um MED/infração é atualizado.
Diferenciação aprimorada de PIX IN/OUT: Distinção mais clara entre eventos PIX de entrada e saída.

Tipos de Evento Padronizados

Os seguintes tipos de evento agora são consistentes em todos os sistemas:

pix.in.completed - PIX de entrada concluído
pix.out.completed - PIX de saída concluído
pix.out.failed - PIX de saída falhou
qrcode.paid - QR Code foi pago
pix.refund.completed - Devolução concluída
pix.refund.failed - Devolução falhou
pix.med.opened - MED/Infração aberta
pix.med.updated - MED/Infração atualizada

Documentação

Tradução completa para inglês: Especificação OpenAPI e coleção Postman agora estão totalmente em inglês.
Documentação de tipos de evento atualizada: Toda a documentação de webhooks atualizada com os tipos de evento padronizados.
Melhorias de consistência: Tipos de evento agora são consistentes entre frontend, handlers da API e documentação.

Breaking Changes

Tipos de evento legados (pix.received, pix.cash_in, pix.cash_out) estão depreciados em favor dos novos tipos padronizados.
Assinaturas de webhook existentes usando tipos de evento antigos continuarão funcionando, mas devem ser migradas.

v1.3.0 (2026-01-29) - Estatísticas de QR Code e Webhooks de Cobrança

Novas Funcionalidades

Estatísticas de QR Code

Novo endpoint GET /v1/pix/qr-codes/stats: Retorna estatísticas agregadas de QR Code das últimas 24 horas.
- Número de QR Codes gerados, pagos e devolvidos
- Valores totais (gerados, pagos, devolvidos)
- Taxa de conversão (pagos/gerados)
- Dados agregados por hora para análise de tendência

Webhooks de Cobrança (COB)

Notificações de pagamento de QR Code: Quando um QR Code dinâmico é pago, o sistema atualiza automaticamente o status do QR Code para PAID e notifica via webhook.
Evento qrcode.paid: Webhook enviado quando um QR Code é confirmado como pago pelo BACEN.
Registro automático de webhook: Ao criar uma chave PIX, o webhook de cobrança é registrado automaticamente para receber notificações de pagamento.

Correções de Bugs

Corrigida a exibição de valores de saldo.
Corrigidos valores de transações no extrato.

Documentação

Adicionado endpoint de estatísticas de QR Code à especificação OpenAPI.
Atualizada a coleção Postman com o novo endpoint de estatísticas.

v1.2.0 (2026-01-27) - Portal do Integrador e Webhooks

Novas Funcionalidades

Portal do Integrador: Documentação adicionada com link do portal e funcionalidades.

Alterações

Webhooks via Portal: A configuração de webhooks agora ocorre exclusivamente pelo Portal do Integrador.
Documentação ajustada: Removidas referências a endpoints públicos de gerenciamento de webhooks; apenas POST /webhooks/replay e GET /v1/webhooks/events mantidos.

v1.1.0 (2026-01-27) - Gerenciamento de Webhooks via API

Novas Funcionalidades

Webhooks Self-Service

CRUD de Webhook via API: Agora você pode criar, listar, atualizar e excluir configurações de webhook diretamente via API sem precisar contatar o suporte.
Múltiplos Tipos de Autenticação: Suporte para HMAC, API_KEY, BASIC, BEARER e IP_WHITELIST para autenticação de webhooks.
Filtro por Tipo de Evento: Configure quais tipos de evento cada webhook deve receber.
Endpoint de Eventos Disponíveis: Novo endpoint GET /v1/webhooks/events para listar todos os tipos de evento suportados.

Novos Eventos de Webhook

pix.pending: Novo evento enviado quando um Pix está pendente de confirmação (útil para rastreamento de pagamento em tempo real).
pix.qrcode.cash_in: Evento específico para pagamentos de QR Code via cobrança.

Segurança

Restrição de IP para Webhooks: Endpoints de webhook agora suportam restrição de IP de origem.

Correções de Bugs

Documentação de webhooks aprimorada com exemplos mais detalhados.
Corrigidos exemplos de payload em eventos de webhook.

v1.0.0 (2025-12-29) - Lançamento Inicial (API CorpX)

Esta é a primeira versão oficial da documentação pública unificada da API CorpX, focada em integradores externos e parceiros bancários.

Principais Funcionalidades

Pix e Pagamentos

Pix Out: Transferências instantâneas usando chaves Pix em um único passo.
QR Codes: Geração de QR Code dinâmico e estático, com suporte para captura, consulta de status e cancelamento.
Devoluções: Fluxo de devolução para Pix recebidos.
Pix MED: Suporte completo ao Mecanismo Especial de Devolução para gestão de infrações e disputas.

Gestão de Conta

Consulta de Saldo: Visualização detalhada de saldo total, disponível e bloqueado.
Extrato: Histórico paginado de transações e movimentações da conta.
Transferências Internas: Movimentação P2P de recursos entre contas na mesma plataforma.

Webhooks e Notificações

Notificações de Saída: Recepção automática de eventos (Pix recebido, Pix enviado, atualizações de MED).
Segurança: Assinatura HMAC-SHA256 em todas as notificações para garantia de origem.
Retries: Sistema automático de retry com exponential backoff.
Replay Self-Service: Endpoints para solicitar reenvio de notificações (Individual ou em Lote) via API.

Segurança e Idempotência

Autenticação: OAuth2 via Identity Provider (fluxos client_credentials e authorization_code).
Idempotência: Garantia de execução única para operações mutáveis via header Idempotency-Key.
Assinatura de Transação: Todas as operações de transferência Pix são protegidas por assinaturas RSA-SHA512.

Suporte Multi-idioma

Documentação disponível em Português, Inglês e Chinês Simplificado.

Experiência do Desenvolvedor

OpenAPI 3.0: Especificação completa disponível para download e Swagger UI interativo.
Coleção Postman: Coleção pronta para uso para testes no ambiente Sandbox.
Guia do Integrador: Documentação detalhada sobre headers, erros e boas práticas.

v2.53.0 (2026-08-07) - maxLookupRatio sai, e os limites por janela passam a valer sempre
v2.51.0 (2026-08-07) - Limites de consulta de chave por janela de tempo
v2.50.0 (2026-08-07) - O titular volta para o seu app ao fim do onboarding e da portabilidade
v2.49.1 (2026-08-07) - account_not_entitled passa a valer também no extrato e no saldo diário
v2.49.0 (2026-08-06) - Serviço não habilitado na conta deixa de parecer falha temporária nossa
v2.48.0 (2026-08-06) - Recusa do liquidante deixa de ser lida como limite da sua conta
v2.47.0 (2026-08-06) - O piso do ratio cai para 50 e o default do maxLookupRatio sobe para 4
v2.46.0 (2026-08-05) - Todo limite de consulta de chave passa a ser medido por conta
v2.45.1 (2026-08-05) - Chave inexistente no DICT volta a ser reconhecida como tal
v2.45.0 (2026-08-05) - Conta ainda em credenciamento responde 409, não erro de comunicação
v2.44.3 (2026-08-05) - Consulta de chave recusada passa a consumir a cota diária
v2.44.2 (2026-08-05) - Pagamento de QR Code sem identificador deixa de passar em branco
v2.44.1 (2026-08-05) - method do PIX recebido diz se veio de QR Code
v2.43.4 (2026-08-03) - Credenciamento não é mais recusado por complemento curto
v2.43.3 (2026-08-03) - Reenvio de pagamento recusado volta a executar
v2.43.1 (2026-07-31) - Credencial de recebimento sem acesso a saldo e extrato
v2.43.0 (2026-07-31) - Escopos granulares nas credenciais de integração
v2.42.0 (2026-07-30) - Suspensão temporária de acesso por pendência
v2.41.1 (2026-07-30) - Transferência interna recusada não volta mais como pendente
v2.41.0 (2026-07-29) - Estorno parcial de PIX recebido
v2.40.0 (2026-07-29) - Todas as regras do painel passam a valer
v2.39.0 (2026-07-29) - Erros do liquidante deixam de ser genéricos
v2.38.0 (2026-07-28) - Regras de PIX out passam a valer, com aviso por webhook
v2.37.3 (2026-07-28) - Correção: PIX out por QR Code sem valor
v2.37.2 (2026-07-28) - Correção: ted.in.received voltou a ser entregue
v2.37.1 (2026-07-26) - Portabilidade automática passa a depender de habilitação
v2.37.0 (2026-07-25) - Abertura PF de CPF que já tem conta (autorização do titular)
v2.36.1 (2026-07-25) - pixLimits removido do accreditation
v2.36.0 (2026-07-25) - API de alteração de limites PIX desativada
v2.35.0 (2026-07-23) - Webhooks de MED (disputas) voltaram
v2.34.3 (2026-07-23) - Tarifas CorpX no extrato sem prefixo fee-*
v2.34.2 (2026-07-23) - Entrega confiável dos webhooks de TED
v2.34.1 (2026-07-23) - payer/payee em pix.refund.completed externo
v2.34.0 (2026-07-23) - Documentos societários no accreditation PJ
v2.33.2 (2026-07-21) - Guard de destino ambíguo na transferência interna por documento
v2.33.1 (2026-07-21) - Link de aceite BYO + webhooks de accreditation
v2.33.0 (2026-07-21) - Cancelamento de accreditation + docs sem dedup
v2.32.0 (2026-07-19) - Deprecação do PIX out QR Code síncrono
v2.31.0 (2026-07-19) - PIX out QR Code (copia e cola) assíncrono
v2.30.0 (2026-07-18) - Onboarding: CPF/CNPJ só atrela ao tenant após biometria
v2.29.2 (2026-07-15) - PIX out: timeout de comunicação não emite mais pix.out.failed
v2.28.2 (2026-07-10) - Webhook pix.out.timeout
v2.28.1 (2026-07-10) - Devolução PIX: somente estorno total
v2.27.0 (2026-07-08) - Credenciais somente leitura
v2.26.0 (2026-07-08) - Habilitação por tenant do credenciamento
v2.25.0 (2026-07-08) - Abertura de contas self-service com biometria facial
v2.24.2 (2026-07-07) - Dados do pagador e recebedor em webhooks e lookup de QR
v2.24.1 (2026-07-07) - Extrato: status por transação não liquidada
v2.24.0 (2026-07-07) - PIX out: rejeições imediatas e análise de risco
v2.22.0 (2026-07-02) - TED com caminho canônico próprio
v2.21.0 (2026-07-01) - Normalização de IDs de boleto
v2.20.1 (2026-06-15) - fee.charged e fee.refunded para tarifas externas
v2.20.0 (2026-06-12) - Limites de DICT lookup e cache de 24h
v2.19.1 (2026-06-11) - Correção: webhook pix.refund.received indevido em devoluções emitidas
v2.19.0 (2026-06-10) - Fim do limite de R$ 15.000 por transação PIX; BigPix descontinuado
v2.18.3 (2026-06-09) - Webhooks para transferências internas externas
v2.18.2 (2026-06-07) - Erro de devolução (refund) mais preciso
v2.18.1 (2026-06-07) - Saldo é somente leitura (sem bloqueio do nosso lado)
v2.18.0 (2026-06-06) - Saldos diários, contraparte enriquecida e novos filtros no extrato
v2.17.0 (2026-06-05) - Limite do identifier ampliado para 38 caracteres
v2.16.0 (2026-06-02) - Extrato legacy (pré-cutover)
v2.15.0 (2026-05-30) - Export de extrato reativado
v2.14.0 (2026-05-30) - Consulta de dados bancários da conta
v2.13.0 (2026-05-25) - Decode de QR Code mais rico
v2.12.1 (2026-05-24) - PIX status PENDING_APPROVAL
v2.12.0 (2026-05-23) - TED disponível (envio + recebimento)
- Endpoints novos
- Webhooks novos
- Janela e tempos
- Deprecação
v2.11.1 (2026-05-22) - Correção: webhook duplicado em tenants com múltiplas subscriptions
v2.11.0 (2026-05-22) - Envelope de webhook alinhado ao formato v1
- Compatibilidade
v2.10.0 (2026-05-22) - Vocabulário de refund alinhado ao banco parceiro
v2.9.0 (2026-05-21) - Documento da contraparte no extrato
v2.0 (2026-05-21) - Nova plataforma CorpX
- Auth
- Statement consolidado em um único endpoint
- Endpoints deprecated (ainda funcionam até 2026-11-21)
- Endpoints removidos (retornam 404 na v2)
- Endpoints novos
- Mudanças de comportamento (mesmo path, novo shape ou semântica)
- MED e webhooks temporariamente suspensos
- Compat (sem mudança no seu código)
- Suporte
v1.30.3 (2026-04-30) - Eliminação de webhooks duplicados (pix.refund.completed, pix.out.failed, qrcode.paid)
- Correções
- Diferenças que somem (apenas para integrações que estavam acopladas ao formato legado, não documentado)
- Recomendação para deduplicação
v1.30.2 (2026-04-30) - Padronização de timestamps em UTC nos webhooks
- Correções
v1.30.1 (2026-04-29) - Webhook qrcode.paid mantido (não será descontinuado)
- Reversão de descontinuação
v1.30.0 (2026-04-23) - Correções em transferências internas (mapeamento de erro + identifier no webhook)
- Correções
- Melhorias
- Novos errorCode retornados
v1.29.0 (2026-04-18) - Consulta de destinatário de transferência interna por documento
- Novos recursos
- Fluxo recomendado
v1.28.0 (2026-04-17) - Remoção de webhooks deprecated
- Breaking Changes
v1.27.0 (2026-04-14) - PIX Out por dados bancários
- Novos recursos
- Observações
v1.26.1 (2026-04-13) - Correções de estabilidade
- Correções
v1.26.0 (2026-04-09) - Pagamento de boleto
- Novos recursos
- Observações
v1.25.1 (2026-04-02) - Referência da transação original em fee.charged e melhorias de devoluções
- Melhorias
v1.25.0 (2026-03-26) - Campo payerDescription, webhooks de tarifas e correções de devoluções
- Novos recursos
- Melhorias
- Correções
v1.24.1 (2026-03-18) - Semântica de erros (redução de 502 genérico)
- Melhorias
- Mapeamento de erros alterados (de -> para)
v1.24.0 (2026-03-18) - Pix Out síncrono: rate limit por conta e timeout 207
- Breaking Changes
- Melhorias
v1.23.0 (2026-03-17) - Consulta de QR Code PIX (Decode)
- Novas funcionalidades
v1.22.0 (2026-03-07) - Transferência interna por documento e por agência/conta
- Novas funcionalidades
v1.20.0 (2026-03-01) - Validação de propriedade de conta
- Melhorias
v1.19.1 (2026-02-26) - Melhoria no BigPix
- Melhorias
v1.19.0 (2026-02-26) - Timeline de transação
- Novas funcionalidades
v1.18.0 (2026-02-24) - Otimizações de performance e tarifas independentes
- Melhorias
- Correções
v1.17.0 (2026-02-22) - Reconciliação automática e correção de status de transações
- Melhorias
v1.16.2 (2026-02-21) - Consultas enriquecidas de QR Code e Pagamentos
- Melhorias
v1.16.1 (2026-02-21) - Correções de respostas de parceiro
- Correções
v1.16.0 (2026-02-20) - Endpoints de Lookup e Paginação de Pagamentos
- Novas Funcionalidades
- Deprecated
v1.15.0 (2026-02-20) - Campo method nos webhooks e reconciliacao de refunds
- Novas Funcionalidades
- Deprecated
v1.14.0 (2026-01-16) - BigPix: Transferências de alto valor
- Novas Funcionalidades
v1.13.2 (2026-01-16) - Melhorias na entrega de webhooks
- Melhorias
v1.13.1 (2026-02-19) - Remoção de qrCodeFormat e Fluxo de Aprovação
- Breaking Changes
- Novas Funcionalidades
v1.13.0 (2026-02-18) - Disputas (MED), Políticas com Enforcement e Contestação
- Novas Funcionalidades
- Melhorias
v1.12.1 (2026-02-18) - Refund Reason Obrigatório e Correção de Paginação
- Novas Funcionalidades
- Breaking Changes
- Melhorias
- Correções
v1.12.0 (2026-02-18) - Policy Engine
- Novas Funcionalidades
v1.11.1 (2026-02-15) - Correções no Extrato
- Correções
v1.11.0 (2026-02-15) - Tarifas Bancárias no Extrato e Webhook fee.charged
- Novas Funcionalidades
v1.10.0 (2026-02-13) - Reconciliation ID, Suporte a Devoluções via Reversal
- Novas Funcionalidades
- Correções
v1.9.0 (2026-02-13) - Lifecycle de Pagamentos, Correções de QR Code e Webhooks
- Novas Funcionalidades
- Correções
v1.8.0 (2026-02-11) - Extrato Enriquecido e Correção de Assinatura de Webhook
- Novas Funcionalidades
- Correções
v1.7.0 (2026-02-11) - Formato de Webhook, Autenticação Configurável e Assinatura HMAC
- Breaking Changes
- Novas Funcionalidades
- Melhorias
- Correções
v1.6.0 (2026-02-06) - Padronização de Moeda, Sincronização de Extrato e Validação de Valores
- Novas Funcionalidades
- Melhorias
v1.5.0 (2026-02-05) - Padronização de URLs, API de Pagamentos e Correção de QR Code
- Breaking Changes
- Novas Funcionalidades
- Correções de Bugs
v1.4.0 (2026-01-16) - Padronização de Tipos de Evento de Webhook e Documentação
- Novas Funcionalidades
- Documentação
- Breaking Changes
v1.3.0 (2026-01-29) - Estatísticas de QR Code e Webhooks de Cobrança
- Novas Funcionalidades
- Correções de Bugs
- Documentação
v1.2.0 (2026-01-27) - Portal do Integrador e Webhooks
- Novas Funcionalidades
- Alterações
v1.1.0 (2026-01-27) - Gerenciamento de Webhooks via API
- Novas Funcionalidades
- Correções de Bugs
v1.0.0 (2025-12-29) - Lançamento Inicial (API CorpX)
- Principais Funcionalidades
- Suporte Multi-idioma
- Experiência do Desenvolvedor

v2.53.0 (2026-08-07) - maxLookupRatio sai, e os limites por janela passam a valer sempre​

v2.51.0 (2026-08-07) - Limites de consulta de chave por janela de tempo​

v2.50.0 (2026-08-07) - O titular volta para o seu app ao fim do onboarding e da portabilidade​

v2.49.1 (2026-08-07) - account_not_entitled passa a valer também no extrato e no saldo diário​

v2.49.0 (2026-08-06) - Serviço não habilitado na conta deixa de parecer falha temporária nossa​

v2.48.0 (2026-08-06) - Recusa do liquidante deixa de ser lida como limite da sua conta​

v2.47.0 (2026-08-06) - O piso do ratio cai para 50 e o default do maxLookupRatio sobe para 4​

v2.46.0 (2026-08-05) - Todo limite de consulta de chave passa a ser medido por conta​

v2.45.1 (2026-08-05) - Chave inexistente no DICT volta a ser reconhecida como tal​

v2.45.0 (2026-08-05) - Conta ainda em credenciamento responde 409, não erro de comunicação​

v2.44.3 (2026-08-05) - Consulta de chave recusada passa a consumir a cota diária​

v2.44.2 (2026-08-05) - Pagamento de QR Code sem identificador deixa de passar em branco​

v2.44.1 (2026-08-05) - method do PIX recebido diz se veio de QR Code​

v2.43.4 (2026-08-03) - Credenciamento não é mais recusado por complemento curto​

v2.43.3 (2026-08-03) - Reenvio de pagamento recusado volta a executar​

v2.43.1 (2026-07-31) - Credencial de recebimento sem acesso a saldo e extrato​

v2.43.0 (2026-07-31) - Escopos granulares nas credenciais de integração​

v2.42.0 (2026-07-30) - Suspensão temporária de acesso por pendência​

v2.41.1 (2026-07-30) - Transferência interna recusada não volta mais como pendente​

v2.41.0 (2026-07-29) - Estorno parcial de PIX recebido​

v2.40.0 (2026-07-29) - Todas as regras do painel passam a valer​

v2.39.0 (2026-07-29) - Erros do liquidante deixam de ser genéricos​

v2.38.0 (2026-07-28) - Regras de PIX out passam a valer, com aviso por webhook​

v2.37.3 (2026-07-28) - Correção: PIX out por QR Code sem valor​

v2.37.2 (2026-07-28) - Correção: ted.in.received voltou a ser entregue​

v2.37.1 (2026-07-26) - Portabilidade automática passa a depender de habilitação​

v2.37.0 (2026-07-25) - Abertura PF de CPF que já tem conta (autorização do titular)​

v2.36.1 (2026-07-25) - pixLimits removido do accreditation​

v2.36.0 (2026-07-25) - API de alteração de limites PIX desativada​

v2.35.0 (2026-07-23) - Webhooks de MED (disputas) voltaram​

v2.34.3 (2026-07-23) - Tarifas CorpX no extrato sem prefixo fee-*​

v2.34.2 (2026-07-23) - Entrega confiável dos webhooks de TED​

v2.34.1 (2026-07-23) - payer/payee em pix.refund.completed externo​

v2.34.0 (2026-07-23) - Documentos societários no accreditation PJ​

v2.33.2 (2026-07-21) - Guard de destino ambíguo na transferência interna por documento​

v2.33.1 (2026-07-21) - Link de aceite BYO + webhooks de accreditation​

v2.33.0 (2026-07-21) - Cancelamento de accreditation + docs sem dedup​

v2.32.0 (2026-07-19) - Deprecação do PIX out QR Code síncrono​

v2.31.0 (2026-07-19) - PIX out QR Code (copia e cola) assíncrono​

v2.30.0 (2026-07-18) - Onboarding: CPF/CNPJ só atrela ao tenant após biometria​

v2.29.2 (2026-07-15) - PIX out: timeout de comunicação não emite mais pix.out.failed​

v2.28.2 (2026-07-10) - Webhook pix.out.timeout​

v2.28.1 (2026-07-10) - Devolução PIX: somente estorno total​

v2.27.0 (2026-07-08) - Credenciais somente leitura​

v2.26.0 (2026-07-08) - Habilitação por tenant do credenciamento​

v2.25.0 (2026-07-08) - Abertura de contas self-service com biometria facial​

v2.24.2 (2026-07-07) - Dados do pagador e recebedor em webhooks e lookup de QR​

v2.24.1 (2026-07-07) - Extrato: status por transação não liquidada​

v2.24.0 (2026-07-07) - PIX out: rejeições imediatas e análise de risco​

v2.22.0 (2026-07-02) - TED com caminho canônico próprio​

v2.21.0 (2026-07-01) - Normalização de IDs de boleto​

v2.20.1 (2026-06-15) - fee.charged e fee.refunded para tarifas externas​

v2.20.0 (2026-06-12) - Limites de DICT lookup e cache de 24h​

v2.19.1 (2026-06-11) - Correção: webhook pix.refund.received indevido em devoluções emitidas​

v2.19.0 (2026-06-10) - Fim do limite de R$ 15.000 por transação PIX; BigPix descontinuado​

v2.18.3 (2026-06-09) - Webhooks para transferências internas externas​

v2.18.2 (2026-06-07) - Erro de devolução (refund) mais preciso​

v2.18.1 (2026-06-07) - Saldo é somente leitura (sem bloqueio do nosso lado)​

v2.18.0 (2026-06-06) - Saldos diários, contraparte enriquecida e novos filtros no extrato​

v2.17.0 (2026-06-05) - Limite do identifier ampliado para 38 caracteres​

v2.16.0 (2026-06-02) - Extrato legacy (pré-cutover)​

v2.15.0 (2026-05-30) - Export de extrato reativado​

v2.14.0 (2026-05-30) - Consulta de dados bancários da conta​

v2.13.0 (2026-05-25) - Decode de QR Code mais rico​

v2.12.1 (2026-05-24) - PIX status PENDING_APPROVAL​

v2.12.0 (2026-05-23) - TED disponível (envio + recebimento)​

Endpoints novos​

Webhooks novos​

Janela e tempos​

Deprecação​

v2.11.1 (2026-05-22) - Correção: webhook duplicado em tenants com múltiplas subscriptions​

v2.11.0 (2026-05-22) - Envelope de webhook alinhado ao formato v1​

Compatibilidade​

v2.10.0 (2026-05-22) - Vocabulário de refund alinhado ao banco parceiro​

v2.9.0 (2026-05-21) - Documento da contraparte no extrato​

v2.0 (2026-05-21) - Nova plataforma CorpX​

Auth​

Statement consolidado em um único endpoint​

Endpoints deprecated (ainda funcionam até 2026-11-21)​

Endpoints removidos (retornam 404 na v2)​

v2.53.0 (2026-08-07) - `maxLookupRatio` sai, e os limites por janela passam a valer sempre

v2.51.0 (2026-08-07) - Limites de consulta de chave por janela de tempo

v2.50.0 (2026-08-07) - O titular volta para o seu app ao fim do onboarding e da portabilidade

v2.49.1 (2026-08-07) - `account_not_entitled` passa a valer também no extrato e no saldo diário

v2.49.0 (2026-08-06) - Serviço não habilitado na conta deixa de parecer falha temporária nossa

v2.48.0 (2026-08-06) - Recusa do liquidante deixa de ser lida como limite da sua conta

v2.47.0 (2026-08-06) - O piso do ratio cai para 50 e o default do `maxLookupRatio` sobe para 4

v2.46.0 (2026-08-05) - Todo limite de consulta de chave passa a ser medido por conta

v2.45.1 (2026-08-05) - Chave inexistente no DICT volta a ser reconhecida como tal

v2.45.0 (2026-08-05) - Conta ainda em credenciamento responde `409`, não erro de comunicação

v2.44.3 (2026-08-05) - Consulta de chave recusada passa a consumir a cota diária

v2.44.2 (2026-08-05) - Pagamento de QR Code sem identificador deixa de passar em branco

v2.44.1 (2026-08-05) - `method` do PIX recebido diz se veio de QR Code

v2.43.4 (2026-08-03) - Credenciamento não é mais recusado por complemento curto

v2.43.3 (2026-08-03) - Reenvio de pagamento recusado volta a executar

v2.43.1 (2026-07-31) - Credencial de recebimento sem acesso a saldo e extrato

v2.43.0 (2026-07-31) - Escopos granulares nas credenciais de integração

v2.42.0 (2026-07-30) - Suspensão temporária de acesso por pendência

v2.41.1 (2026-07-30) - Transferência interna recusada não volta mais como pendente

v2.41.0 (2026-07-29) - Estorno parcial de PIX recebido

v2.40.0 (2026-07-29) - Todas as regras do painel passam a valer

v2.39.0 (2026-07-29) - Erros do liquidante deixam de ser genéricos

v2.38.0 (2026-07-28) - Regras de PIX out passam a valer, com aviso por webhook

v2.37.3 (2026-07-28) - Correção: PIX out por QR Code sem valor

v2.37.2 (2026-07-28) - Correção: `ted.in.received` voltou a ser entregue

v2.37.1 (2026-07-26) - Portabilidade automática passa a depender de habilitação

v2.37.0 (2026-07-25) - Abertura PF de CPF que já tem conta (autorização do titular)

v2.36.1 (2026-07-25) - `pixLimits` removido do accreditation

v2.36.0 (2026-07-25) - API de alteração de limites PIX desativada

v2.35.0 (2026-07-23) - Webhooks de MED (disputas) voltaram

v2.34.3 (2026-07-23) - Tarifas CorpX no extrato sem prefixo `fee-*`

v2.34.2 (2026-07-23) - Entrega confiável dos webhooks de TED

v2.34.1 (2026-07-23) - `payer`/`payee` em `pix.refund.completed` externo

v2.34.0 (2026-07-23) - Documentos societários no accreditation PJ

v2.33.2 (2026-07-21) - Guard de destino ambíguo na transferência interna por documento

v2.33.1 (2026-07-21) - Link de aceite BYO + webhooks de accreditation

v2.33.0 (2026-07-21) - Cancelamento de accreditation + docs sem dedup

v2.32.0 (2026-07-19) - Deprecação do PIX out QR Code síncrono

v2.31.0 (2026-07-19) - PIX out QR Code (copia e cola) assíncrono

v2.30.0 (2026-07-18) - Onboarding: CPF/CNPJ só atrela ao tenant após biometria

v2.29.2 (2026-07-15) - PIX out: timeout de comunicação não emite mais `pix.out.failed`

v2.28.2 (2026-07-10) - Webhook `pix.out.timeout`

v2.28.1 (2026-07-10) - Devolução PIX: somente estorno total

v2.27.0 (2026-07-08) - Credenciais somente leitura

v2.26.0 (2026-07-08) - Habilitação por tenant do credenciamento

v2.25.0 (2026-07-08) - Abertura de contas self-service com biometria facial

v2.24.2 (2026-07-07) - Dados do pagador e recebedor em webhooks e lookup de QR

v2.24.1 (2026-07-07) - Extrato: status por transação não liquidada

v2.24.0 (2026-07-07) - PIX out: rejeições imediatas e análise de risco

v2.22.0 (2026-07-02) - TED com caminho canônico próprio

v2.21.0 (2026-07-01) - Normalização de IDs de boleto

v2.20.1 (2026-06-15) - `fee.charged` e `fee.refunded` para tarifas externas

v2.20.0 (2026-06-12) - Limites de DICT lookup e cache de 24h

v2.19.1 (2026-06-11) - Correção: webhook `pix.refund.received` indevido em devoluções emitidas

v2.19.0 (2026-06-10) - Fim do limite de R$ 15.000 por transação PIX; BigPix descontinuado

v2.18.3 (2026-06-09) - Webhooks para transferências internas externas

v2.18.2 (2026-06-07) - Erro de devolução (refund) mais preciso

v2.18.1 (2026-06-07) - Saldo é somente leitura (sem bloqueio do nosso lado)

v2.18.0 (2026-06-06) - Saldos diários, contraparte enriquecida e novos filtros no extrato

v2.17.0 (2026-06-05) - Limite do `identifier` ampliado para 38 caracteres

v2.16.0 (2026-06-02) - Extrato legacy (pré-cutover)

v2.15.0 (2026-05-30) - Export de extrato reativado

v2.14.0 (2026-05-30) - Consulta de dados bancários da conta

v2.13.0 (2026-05-25) - Decode de QR Code mais rico

v2.12.1 (2026-05-24) - PIX status `PENDING_APPROVAL`

v2.12.0 (2026-05-23) - TED disponível (envio + recebimento)

Endpoints novos

Webhooks novos

Janela e tempos

Deprecação

v2.11.1 (2026-05-22) - Correção: webhook duplicado em tenants com múltiplas subscriptions

v2.11.0 (2026-05-22) - Envelope de webhook alinhado ao formato v1

Compatibilidade

v2.10.0 (2026-05-22) - Vocabulário de refund alinhado ao banco parceiro

v2.9.0 (2026-05-21) - Documento da contraparte no extrato

v2.0 (2026-05-21) - Nova plataforma CorpX

Auth

Statement consolidado em um único endpoint

Endpoints deprecated (ainda funcionam até 2026-11-21)

Endpoints removidos (retornam 404 na v2)