Recuperar o histórico da sessão
Consulte a trilha de auditoria de alterações, pagamentos e expirações de uma sessão.
GET /v1/sessions/{id}/history retorna um array de eventos em ordem decrescente, com os registros mais recentes primeiro. Cada elemento descreve uma mudança ou um efeito observado (criação, atualização, tentativa de pagamento, confirmação assíncrona, expiração, entre outros).
multiplePayments.status agora, consulte Recuperar detalhes de uma sessão.Quando usar
| Objetivo | Endpoint recomendado |
|---|---|
Disponibilidade do link 1:N (multiplePayments, contadores) | GET /v1/sessions/{id} |
| Linha do tempo de alterações e pagamentos | GET /v1/sessions/{id}/history |
| Conciliação de uma cobrança específica | Histórico + detalhe da cobrança em Charges |
GET /v1/sessions/{id}.
Modelo da resposta
Cada item do array possui os campos abaixo.| Campo | Descrição |
|---|---|
id | Identificador do registro de histórico, não da sessão. |
status | Status na leitura do produto: created, paid, canceled, voided ou disabled. |
createdAt, updatedAt | Timestamps do registro (RFC 3339, com milissegundos). |
clientId, merchantId | Preenchidos quando gravados na auditoria. |
action | Ação principal derivada de actions (pode ser null quando dados legados não permitem derivar uma ação semântica com segurança). |
actions | Lista completa de ações semânticas do evento. |
diff | Objeto JSON com changes, reason e contexto do fluxo. |
Status disabled no histórico
O valor disabled não é um status persistido na sessão. Ele aparece no histórico quando o registro representa expiração automática por:
- vencimento do
dueDate(sessionExpiredByDueDate); ou - limite de pagamentos em sessão 1:N (
sessionExpiredByMaxPayments).
canceled.
Prioridade do campo action
Quando há várias entradas em actions, a API escolhe uma ação principal nesta ordem:
statusChangedsessionExpiredByDueDatesessionExpiredByMaxPaymentspaymentExpiredupdated(genérico para demais combinações)
Catálogo de ações (actions)
As ações abaixo podem aparecer isoladas ou combinadas no mesmo registro.
Alterações de sessão
| Action | Significado |
|---|---|
statusChanged | Mudança de status (criação, cancelamento, confirmação paid, voided, etc.). |
amountChanged, currencyChanged | Valor ou moeda alterados. |
isActiveChanged | Link ativado ou desativado (manualActivation / manualDeactivation no diff). |
itemsChanged, itemsRemoved | Itens do pedido alterados ou removidos. |
dueDateChanged, maxPaymentsChanged | Vencimento ou limite 1:N alterados. |
nameChanged, descriptionChanged, captchaEnabledChanged | Demais campos de configuração. |
splitRulesChanged | Regras de split atualizadas (ex.: enriquecimento de recebedor). |
Pagamentos e estoque 1:N
| Action | Significado |
|---|---|
paymentSucceeded | Resposta não falha da tentativa de cobrança HTTP (inclui pending) ou confirmação assíncrona idempotente. |
paymentFailed | Falha HTTP, erro de transporte ou corpo da resposta com status=failed. |
paymentPending | Reserva de vaga pendente em sessão 1:N (Pix/boleto assíncrono). |
paymentExpired | Pagamento pendente expirado; libera a reserva pendente e pode reativar o link. |
Expirações e bloqueios
| Action | Significado |
|---|---|
sessionExpiredByDueDate | Link desativado ao vencer dueDate (status na API: disabled). |
sessionExpiredByMaxPayments | Limite 1:N atingido; link desativado (status na API: disabled). |
sessionExpiredByInvalidSeller | Seller inválido; sessão encerrada (status: canceled). |
captchaBlocked | Bloqueio por score de captcha. |
Fluxo de registro (visão geral)
Dois destinos distintos: o histórico registra o que aconteceu; a sessão e as métricas guardam o estado atual do link.Trilha de auditoria
Cada origem abaixo pode acrescentar um evento ao histórico. Consulte o resultado comGET /v1/sessions/{id}/history.
Estado agregado do link
As mesmas origens também atualizam contadores e disponibilidade do link. Para o estado atual, useGET /v1/sessions/{id} — não o histórico.
Registros com deduplicação por cobrança (paymentPending, paymentSucceeded, paymentExpired em 1:N) evitam reaplicar o mesmo efeito em reprocessamentos. Tentativas HTTP de cobrança não são deduplicadas: cada chamada pode gerar uma nova linha.
Estrutura típica do diff
Atualizações manuais costumam seguir:
dueDate:
chargeId como campo de nível raiz nem metadados de sistema. Quando houver contexto de cobrança, ele pode aparecer dentro de diff, por exemplo em diff.chargeId ou diff.changes.response.to.chargeId.
Erros comuns
| HTTP | Causa |
|---|---|
400 | X-Client-Id ausente ou identificador da sessão ausente no path. |
404 | Sessão inexistente para o par id + X-Client-Id. |
500 | Erro interno inesperado ao recuperar o histórico da sessão. |
Próximos passos
Sessões
Detalhes da sessão
multiplePayments.Path Parameters
Identificação da sessão
Response
OK
Identificador do registro de histórico (não confundir com o id da sessão no path).
Status da sessão na leitura do produto no momento do evento. O valor disabled indica desativação automática por dueDate ou limite de pagamentos 1:N; cancelamento manual permanece canceled.
created, paid, canceled, voided, disabled Data de criação do registro (RFC 3339, com precisão de milissegundos).
Data da última atualização do registro.
Identificador do cliente Malga associado ao registro, quando preenchido.
Identificador do merchant associado ao registro, quando preenchido.
Ação principal derivada de actions, com prioridade documentada (ex.: statusChanged, sessionExpiredByDueDate, paymentSucceeded). Pode ser omitida (null) quando o diff indica expiração por dueDate mas actions não lista sessionExpiredByDueDate.
Lista completa de ações semânticas do evento. Valores possíveis incluem statusChanged, amountChanged, isActiveChanged, paymentSucceeded, paymentPending, paymentExpired, sessionExpiredByDueDate, sessionExpiredByMaxPayments, splitRulesChanged, entre outros.
Objeto JSON com mudanças (changes.*), razões estáveis (reason, changes.isActive.reason) e contexto (ex.: maxPaymentsContext, resposta da tentativa de cobrança em changes.response). A estrutura varia conforme o fluxo.