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_planoe 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_esperamostra 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
| Pergunta | Onde |
|---|---|
| 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
| Param | O que faz |
|---|---|
tipo | Um tipo só. Valor fora de tipos_disponiveis responde 400 nomeando os aceitos — nunca uma lista vazia silenciosa. |
desde | ISO 8601 — só marcos a partir daí. |
ate | ISO 8601 — só marcos até aí. desde depois de ate responde 400. |
limite | 1 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
type | payload |
|---|---|
fonte_ativada | source, previous_source, plan_version_id, reativacao |
trial_perto_do_fim | source_id, plan_version_id, ends_at |
trial_recorrente_concedido | plan_version_id, trial_days, ends_at |
incentivo_resgatado | discount_offer_key, trial_source_id, duration, duration_in_months, percent_off, amount_off, currency |
downgrade_solicitado | plan_version_id |
downgrade_agendado_aplicado_na_stripe | plan_version_id, atrasado, ciclos_cobrados_no_preco_antigo |
assinatura_cancelamento_agendado | status, cancel_at_period_end, current_period_end |
desativacao_por_excesso_de_plano | meter, tabela, quantidade_desativada, motivo |
vitalicio_concedido_em_espera | plan_version_id, fonte_ativa_no_momento |
vitalicio_revogado | source_id, status_anterior, plan_version_id |
creditos_perto_de_vencer | lot_id, vence_em, quantidade_restante |
capacidade_do_sistema_pausada | meter_key, motivo |
compra_pendente_vinculada | pending_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_agendadoresponde "cancelei, quando para?" comcurrent_period_end.downgrade_solicitadoe o aplicado mantêmplan_version_id.incentivo_resgatadomanté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.