Changelog do contrato
A versão do contrato segue 2.MENOR.CORREÇÃO: o primeiro número é o do caminho (/v2) e só
muda quando existir /v3 (mudança que quebra); o do meio sobe a cada adição (rota, campo, código
novo); o último, quando muda só texto ou exemplo. As versões com sufixo -rc.N, na tabela
abaixo, foram as prévias publicadas antes da 2.0.0.
| Versão | Data | Tipo | O que mudou |
|---|---|---|---|
| 2.0.1 | 2026-10-06 | texto | Só documentação: nenhuma rota, campo ou código mudou. O guia Cartão: cofre e cifra ganhou um exemplo completo, do clique ao resultado (servidor cria a intenção, página monta o campo, servidor confirma), com o que fazer em cada resultado do confirm. O guia Webhooks ganhou a seção "Do aviso até a tela do cliente", que mostra como a notícia do pagamento chega à tela de quem está pagando. O arquivo llms-full.txt ficou menor: cada formato é descrito uma vez só, e os exemplos do aviso e do envio ao cofre passaram a vir preenchidos. As descrições de campo não citam mais números de versão antigos. O reenvio de aviso pelo painel passou a constar como "em breve". |
| 2.0.0 | 2026-10-06 | versão final | Primeira versão final do contrato da /v2. Mesmo conteúdo da última prévia (2.0.0-rc.4). A partir daqui vale a regra de versionamento: campo, rota ou valor novo entram na mesma /v2; mudança que quebra só em /v3. |
| 2.0.0-rc.4 | 2026-10-06 | correção | Recebíveis: o status PAID num recebível quer dizer já repassado ao recebedor; enquanto o repasse não acontece ele fica PENDING, com a data prevista em expectedOn. O exemplo de Pix pago foi acertado. Nenhuma rota, campo ou código novo. |
| 2.0.0-rc.3 | 2026-10-05 | adição | Listar transações: GET /v2/transactions passa a listar todas as transações da sua empresa, com paginação. O filtro referenceId deixa de ser obrigatório (quem já manda continua recebendo 0 ou 1 item). Filtros novos, todos opcionais: status e paymentMethod (um ou mais valores cada, separados por vírgula), from, to. Ordenação nova: orderBy (createdAt ou amountCents) e direction (asc ou desc); sem eles, a mais recente vem primeiro. O formato da resposta não muda. |
| 2.0.0-rc.2 | 2026-10-03 | adição | Pix e boleto numa chamada só: campo opcional confirm na criação da intenção (POST /v2/payment-intents). Com confirm: true, a mesma chamada cria e confirma; a resposta traz a intenção CONFIRMED com a transação no campo novo transaction. Só Pix e boleto (cartão → 400 VALIDATION_ERROR). A criação ganha a resposta 502 PROVIDER_ERROR, que só acontece com confirm: true. Nada removido ou renomeado; quem usa os dois passos não muda nada. Entrou também o guia Primeiro Pix no começo desta documentação (só texto). |
| 2.0.0-rc.1 | 2026-10-03 | prévia | Primeira prévia do contrato da /v2. |