> For the complete documentation index, see [llms.txt](https://docs.barte.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.barte.com/changelog/readme.md).
# Changelog
Comunicação de atualizações e melhorias.
### Setembro, 2026
   
#### Assinatura de Webhook com HMAC-SHA256
Os webhooks da Barte passam a suportar assinatura digital via HMAC-SHA256. O recurso é opcional e retrocompatível — quem não configurar continua recebendo webhooks normalmente.
Para ativar, basta informar `generateSecret: true` (geração automática) ou um `secret` próprio de 32 a 64 caracteres no cadastro do webhook via `POST /v2/seller`. Quando configurado, cada entrega passa a incluir três novos headers: `X-Webhook-Timestamp`, `X-Webhook-Nonce` e `X-Webhook-Signature`, que permitem verificar a autenticidade e integridade do payload recebido.
O secret é exibido uma única vez, no momento da criação. Nas consultas subsequentes, a API retorna apenas um preview com os 5 primeiros caracteres.
Veja como implementar a verificação no seu sistema: [Assinatura de Webhook (HMAC-SHA256)](https://docs.barte.com/guias/webhooks/assinatura-de-webhook)
***
   
#### Novo endpoint de estorno de cobrança
O estorno de cobrança passou a ter um endpoint próprio, que atende **cartão de crédito e PIX**, aceita estorno **total ou parcial** e processa de forma **assíncrona**: o `202 Accepted` confirma que a Barte aceitou o pedido, não que o dinheiro já voltou ao comprador.
A resposta devolve o estorno recém-criado, com o `uuid` que identifica aquele estorno específico nos webhooks e no array `refunds[]` da cobrança — o que importa quando há vários estornos parciais na mesma cobrança.
A criação aceita o header opcional `x-idempotency-key`: reenviar a mesma chave para a mesma cobrança devolve o estorno já criado em vez de duplicar. Recomendado para proteger contra retentativas de rede.
Detalhes, códigos de erro e exemplos em [Estornar Cobrança](https://github.com/barte-project/barte-docs/tree/main/api-reference/estorno/estorno-cobranca-novo-fluxo.md).
***
    
#### Estornos agora são identificáveis na consulta de cobrança e no webhook
Cada item de `refunds` na consulta de cobrança passou a informar:
* `uuid` — identificador do estorno, o mesmo que aparece no webhook, para correlacionar os dois;
* `createdAt` — data e hora de criação do estorno, em UTC;
* `idempotencyKey` — a chave enviada no header `x-idempotency-key` ao criar o estorno, quando houver.
O objeto de estorno do webhook v2 de cobrança também passou a trazer o `idempotencyKey`, permitindo reconciliar o evento com o pedido que originou a operação sem depender de identificador nosso.
Os campos são adicionais e nenhum comportamento existente mudou. Uma observação sobre o campo `date`, que continua igual: ele informa a **última atualização** do estorno e muda quando ele sai de `PROCESSING` — para a data em que o estorno foi criado, use `createdAt`.
Estornos criados antes de o identificador existir não trazem `uuid`, e estornos criados sem chave de idempotência não trazem `idempotencyKey` — em ambos os casos o campo é omitido, nunca nulo.
***
### Agosto, 2026
   
#### Consulta de cobrança agora informa o motivo da recusa
A busca de cobrança (`GET /v2/charges/{uuid}`) passou a devolver o campo `failureReason` quando a cobrança está com `status` `FAILED`, com o motivo da recusa informado pelo provedor:
```json
{
"status": "FAILED",
"failureReason": {
"code": "BAR-7006",
"title": "insufficient_funds",
"description": "Saldo Insuficiente",
"action": "Verifique com seu banco emissor se há limite suficiente no cartão. Após, tente novamente"
}
}
```
O conteúdo é o mesmo que a criação de cobrança já devolve no erro 400, então quem trata recusa nos dois fluxos passa a ler a mesma informação em ambos.
Antes, recusas confirmadas de forma assíncrona — caso típico de cartão com autenticação 3DS, em que a recusa chega depois da resposta da criação — só informavam `status: FAILED`, sem motivo. Com isso dá para distinguir saldo insuficiente de suspeita de fraude, cartão inválido ou falha na autenticação, e decidir se vale retentar, pedir outro cartão ou orientar o cliente final.
O campo é adicionado à response e não altera nada de quem já integra. Ele é omitido quando a cobrança não está recusada, e também quando a tentativa recusada não tem motivo informado pelo provedor.
***
### Julho, 2026
   
#### Campo title de pedidos agora aceita 255 caracteres
O campo `title` da criação de pedidos (`POST /v2/orders`) passou a aceitar até **255 caracteres**. O limite anterior era de 60.
A mudança já está disponível em Sandbox e Produção e não exige nenhuma ação de quem já integra: títulos com até 60 caracteres continuam funcionando exatamente como antes.
Com isso, sellers que enviam nomes de produto padronizados — e-commerces e marketplaces, por exemplo — deixam de ter pedidos recusados por exceder o limite do campo. O novo tamanho também vale para o `title` retornado nas responses de pedidos e cobranças.
***
### Março, 2026
   
#### Atualização importante sobre Webhooks na API de Sellers
Clientes que utilizam o campo `webhook` devem iniciar a migração para o novo array `webhooks`.
O campo `webhook` foi oficialmente depreciado e será mantido temporariamente apenas para não quebrar integrações existentes. A nova estrutura permite múltiplos webhooks por seller, com controle de eventos (`domains`), status (`active`) e identificador único (`uuid`).
As responses de `POST`, `GET` e `PATCH` já retornam o array `webhooks` em Sandbox e Produção.
Novas integrações devem utilizar exclusivamente `webhooks`. O campo `webhook` poderá ser removido em versões futuras da API. Veja mais detalhes em: [Alterações nos Endpoints de Sellers – Sandbox e Produção](/guias/alteracoes/alteracoes-nos-endpoints-de-sellers-sandbox-e-producao.md)
***
### Janeiro, 2026
   
#### Atualização importante sobre Early Buyer
Clientes que utilizam o recebimento no fluxo de tempo (timeline) não podem mais realizar transações via Early Buyer.
O Early Buyer é um produto baseado em cálculo de juros e antecipação, o que não se aplica a operações em timeline.\
Manter esse cruzamento gerava inconsistências operacionais.
Tentativas de uso do Early Buyer na API de sellers em operações com timeline resultarão em erro.\
Não há impacto para clientes que já operam fora do fluxo de timeline.
***
### Dezembro, 2025
   
#### Atualização – API de Extrato
A partir de **17/12/2025**, o endpoint **GET /v2/report/statement** passará a incluir um novo campo - uuid - em cada objeto retornado no array de resposta. Esse identificador único foi adicionado para facilitar o tratamento individual dos itens do extrato. [Ver mais detalhes](/guias/alteracoes/api-de-extrato-nova-propriedade-uuid.md).
***
### Outubro, 2025
  
#### Novos campos no objeto de Cobranças (Charges)
A partir do dia **29 de outubro de 2025**, dois novos campos "acquirerAuthorizationCode" e "acquirerAuthorizationNsu" serão retornados no objeto da cobrança (Charge) em ambiente de Sandbox. Veja mais informações sobre os endpoints afetados: [Ver mais detalhes](/guias/alteracoes/codigo-de-autorizacao-e-codigo-nsu.md).
***
   
#### Atualização na API de Vendedores
No dia 15/10/2025, os endpoints da Sellers API v2 (POST, GET e PATCH) passaram a exigir novos campos obrigatórios.\
As alterações já estão em vigor nos ambientes de Sandbox e Produção. Veja mais na referência de cada um: [Criar Vendedor](/api-reference/intermediador-de-pagamentos/gerencie-seus-vendedores/criar-vendedor.md) | [Buscar Vendedor](/api-reference/intermediador-de-pagamentos/gerencie-seus-vendedores/buscar-vendedores.md) | [Atualizar dados bancários do Vendedor](/api-reference/intermediador-de-pagamentos/gerencie-seus-vendedores/atualizar-conta-e-webhooks-de-um-vendedor.md)
***
### Setembro, 2025
#### Transações elegíveis para estorno
Agora, o usuário poderá consultar se uma transação é elegível ou não para um estorno parcial ou total acessando seus detalhes no portal do intermediador. Para saber mais, acesse o Portal do Intermediador.
***
#### Melhoria na lógica com o SDK Web
Antes, era preciso fazer as ações separadamente, como criar sessão, comprador (buyer) e pedido (order). Com essa nova alteração, esse fluxo foi abstraído em uma única chamada, centralizando a lógica e simplificando a integração. Veja mais dentro da seção de SDK.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.barte.com/changelog/readme.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
