ACCOUNT_FINANCIAL_SUMMARY, além dos tipos já existentes.
Assim como ACCOUNT, o tipo ACCOUNT_FINANCIAL_SUMMARY só pode ser solicitado por um usuário com papel de manager. Uma conta sem esse papel recebe 403 ao tentar gerá-lo.
Versão da documentação: 4.2.0
observation ao Solicitar Saque, com uma anotação interna sobre o saque (por exemplo, a referência de um pedido).
observation é somente para uso internoO campo é opcional (máximo de 255 caracteres), é armazenado junto com o saque, mas não é retornado em Buscar Saque nem em Listar Saques.
Versão da documentação: 4.1.0
address de Criar Transação, o campo zipCode foi renomeado para postalCode. A mudança também se reflete no address retornado em Buscar Transação e Listar Transações.
Se sua integração envia ou lê address.zipCode, será necessário migrar para address.postalCode. O tipo e o formato do valor (CEP do Brasil) não mudaram, apenas o nome do campo.
Versão da documentação: 4.0.0
total (quantidade total de itens) deixou de ser retornado nas listagens de transações, depósitos, saques, saques recorrentes (e seus agendamentos), relatórios e reservas.
Se sua integração depende de total para exibir a contagem total de itens, ela vai parar de recebê-lo nesses endpoints. totalPages, currentPage e perPage continuam sendo retornados normalmente.
Versão da documentação: 3.0.0
snapshot, adicional a page/perPage, para manter os resultados e o total estáveis mesmo se novos registros forem criados durante a navegação entre páginas.
snapshot não é um ponteiro para a "próxima página": é um identificador fixo da sessão de paginação. Pegue o valor de snapshot retornado na primeira resposta (feita sem enviar snapshot) e reenvie esse mesmo valor, sem alterá-lo, nas páginas seguintes, junto com page incrementando normalmente e os mesmos filtros/perPage usados originalmente. Se algum desses valores mudar enquanto um snapshot antigo é reenviado, a API retorna erro.
Confira um exemplo completo em Listar Transações.
Versão da documentação: 2.2.0
O exemplo de requisição de Comprovante usava o método GET, mas o endpoint sempre exigiu POST /transaction/{id}/receipt. O exemplo foi corrigido.
Em Buscar Notificação, o histórico de status (statusHistory) documentava um campo timestamp que não existe: o campo real é date, e também estava faltando durationInMilliseconds. O campo error foi corrigido para refletir que retorna null (não uma string vazia) quando não há erro. E o objeto de resposta de cada execução (response) ganhou a documentação do campo responseTime, que já existia na API mas nunca tinha sido documentado.
Versão da documentação: 2.1.1
Ao criar um saque recorrente, a API gera automaticamente todos os agendamentos com base na frequência (a cada X dias/meses, ou em um dia fixo do mês) e na duração informadas. Cada agendamento é processado individualmente, na sua data prevista, como um saque comum.
| Método | Endpoint | Descrição |
|---|---|---|
POST | /recurring-withdrawal | Cria um saque recorrente |
GET | /recurring-withdrawal | Lista saques recorrentes |
GET | /recurring-withdrawal/{id} | Busca um saque recorrente |
GET | /recurring-withdrawal/{id}/schedulings | Lista os agendamentos gerados |
PUT | /recurring-withdrawal/{id}/cancel | Cancela um saque recorrente ativo |
Confira a documentação completa em Saque Recorrente.
Versão da documentação: 2.1.0