ACOMPANHAR / Eventos da conta

O que aconteceu na conta

Trial que começou, trial acabando, desconto resgatado, downgrade aplicado, marcas desativadas, crédito a vencer. Não é o estado de agora — é o histórico, com data.


Pra quê isso me serve

Porque "por que minhas marcas sumiram?" não se responde olhando o estado atual. O plano vigente diz o que a conta é hoje; estes eventos dizem o que aconteceu com ela — e em que dia.

Casos concretos:

  • Suporte no seu produto: o cliente reclama que perdeu uma marca. Você olha desativacao_por_excesso_de_plano e responde com a data e o motivo, em vez de adivinhar.
  • Assistente de IA: "paguei o vitalício e nada mudou" tem resposta — vitalicio_concedido_em_espera mostra que o direito está guardado esperando o trial acabar.
  • Painel interno: uma linha do tempo da conta, sem inventar histórico a partir de snapshots.

Isto não é o ciclo do conteúdo. Nomes parecidos, assuntos distintos: o status de um content conta a vida de UMA peça (rascunho → agendada → publicada), e está em Ciclo de vida do conteúdo. Aqui é a vida da CONTA.

Onde a carteira acaba e isto começa

PerguntaOnde
Quanto crédito eu tenho AGORA?GET .../wallet
Qual lote vence primeiro?GET .../wallet
Em que dia me avisaram que ia vencer?aqui
Qual meu plano hoje?GET .../workspaces/me
Quando meu trial começou, e quando caiu?aqui

A carteira é estado, sempre fresco. Estes eventos são histórico permanente: creditos_perto_de_vencer continua existindo depois de o lote vencer e sumir do extrato — o extrato só mostra lotes vivos.

O endpoint

curl -H "Authorization: Bearer $OUTPOSTED_API_KEY" \
  'https://api.outposted.one/api/v1/workspaces/ws_123/lifecycle-events?limite=20'
{
  "eventos": [
    {
      "id": "7f3c9d20-0000-4000-8000-000000000001",
      "type": "desativacao_por_excesso_de_plano",
      "payload": {
        "meter": "marcas",
        "tabela": "brands",
        "quantidade_desativada": 2,
        "motivo": "fim_de_trial_sem_conversao"
      },
      "occurred_at": "2026-09-20T03:00:12.441Z"
    }
  ],
  "tipos_disponiveis": ["fonte_ativada", "..."],
  "request_id": "req_..."
}

Sempre do mais recente para o mais antigo.

Query params

ParamO que faz
tipoUm tipo só. Valor fora de tipos_disponiveis responde 400 nomeando os aceitos — nunca uma lista vazia silenciosa.
desdeISO 8601 — só marcos a partir daí.
ateISO 8601 — só marcos até aí. desde depois de ate responde 400.
limite1 a 500, padrão 50. Sempre os mais recentes.

Não há cursor: o volume por conta é baixo por natureza (um trial, alguns downgrades, um punhado de avisos). Para percorrer um histórico longo, estreite desde/ate.

Os tipos, e o que cada um carrega

typepayload
fonte_ativadasource, previous_source, plan_version_id, reativacao
trial_perto_do_fimsource_id, plan_version_id, ends_at
trial_recorrente_concedidoplan_version_id, trial_days, ends_at
incentivo_resgatadodiscount_offer_key, trial_source_id, duration, duration_in_months, percent_off, amount_off, currency
downgrade_solicitadoplan_version_id
downgrade_agendado_aplicado_na_stripeplan_version_id, atrasado, ciclos_cobrados_no_preco_antigo
assinatura_cancelamento_agendadostatus, cancel_at_period_end, current_period_end
desativacao_por_excesso_de_planometer, tabela, quantidade_desativada, motivo
vitalicio_concedido_em_esperaplan_version_id, fonte_ativa_no_momento
vitalicio_revogadosource_id, status_anterior, plan_version_id
creditos_perto_de_vencerlot_id, vence_em, quantidade_restante
capacidade_do_sistema_pausadameter_key, motivo
compra_pendente_vinculadapending_purchase_id, kind

Chave ausente em payload é resposta, não dado faltando. E motivo, quando presente, é sempre um slug de lista fechada (fim_de_trial_sem_conversao, saldo_insuficiente) — nunca uma frase escrita por alguém.

tipos_disponiveis vem na resposta com a lista vigente deste servidor. Prefira-a a fixar os valores no seu código: a sua é a lista do dia em que você integrou.

Duas coisas que nunca saem daqui

Estão escritas aqui para que ninguém as acrescente depois achando que foram esquecimento.

1. Evento de suporte devolve o fato, nunca a autoria

Quando alguém da nossa equipe reativa ou revoga um vitalício, o registro interno guarda o motivo que a pessoa escreveu, o número do ticket e a credencial usada — é assim que auditamos o que fazemos. Nada disso sai nesta resposta. De vitalicio_revogado você recebe source_id, status_anterior e plan_version_id: o que aconteceu, sem quem decidiu nem o texto que essa pessoa escreveu pensando que só outra pessoa da casa ia ler.

O mesmo vale para fonte_ativada com reativacao: true: o fato de ter sido restaurado é da conta; a autoria, não.

2. Nenhum identificador da Stripe

Nem id de assinatura, nem de customer, nem de preço, nem de cupom. Correspondência interna não é dado de exibição, e expô-la só aumentaria a superfície sem dar a ninguém nada que dê para usar. Nada de valor se perde:

  • assinatura_cancelamento_agendado responde "cancelei, quando para?" com current_period_end.
  • downgrade_solicitado e o aplicado mantêm plan_version_id.
  • incentivo_resgatado mantém a oferta inteira (percentual, duração, moeda).

Se você precisa amarrar um marco a um objeto da Stripe, o caminho é a própria Stripe, com a sua chave.

Pelo MCP

A tool list_lifecycle_events recebe os mesmos parâmetros e devolve o mesmo corpo — ela chama este mesmo endpoint. Um assistente conectado ao Outposted responde "por que minhas marcas foram desativadas?" sem você escrever código.

Pelo SDK Node

import { Outposted } from '@outposted/node';

const outposted = new Outposted({ apiKey: process.env.OUTPOSTED_API_KEY! });

const { eventos } = await outposted.lifecycleEvents.list('ws_123', {
  tipo: 'desativacao_por_excesso_de_plano',
});

for (const e of eventos) {
  console.log(e.occurred_at, e.payload.meter, e.payload.quantidade_desativada, e.payload.motivo);
}

Quem pode ler

O mesmo corte de GET .../wallet: a chave de API do workspace, ou a sessão de quem está logado no painel. Um marco de uma conta nunca aparece na listagem de outra.

Nesta página