Clientes recuperados e receita recorrente

Estes três indicadores respondem juntos uma pergunta central de retenção: quanto do meu resultado vem de trazer clientes de volta, e quanto vem de quem já era ativo? Todos exigem from e to — não há versão “histórico completo” para eles.

Clientes recuperados

Pergunta: quantos clientes inativos voltaram a comprar no período?

Requisição

curl --request GET \
  --url 'https://public-api.repediu.com.br/v1/stores/{merchantId}/metrics/recovered-customer?from=2026-08-01&to=2026-08-31' \
  --header 'Authorization: Bearer <token>'

Resposta

{ "value": 8 }

Equivale a contar, em Conversões, os itens com isReactivation = true no período — mas já vem pronto, sem paginar.

Receita recuperada

Pergunta: quanto esses clientes recuperados gastaram?

Requisição

curl --request GET \
  --url 'https://public-api.repediu.com.br/v1/stores/{merchantId}/metrics/recovered-revenue?from=2026-08-01&to=2026-08-31' \
  --header 'Authorization: Bearer <token>'

Resposta

{ "value": 642.30 }

Receita recorrente

Pergunta: e a receita de clientes que já eram ativos (não precisaram ser reativados)?

Requisição

curl --request GET \
  --url 'https://public-api.repediu.com.br/v1/stores/{merchantId}/metrics/revenue-recurring?from=2026-08-01&to=2026-08-31' \
  --header 'Authorization: Bearer <token>'

Resposta

{ "value": 10894.50 }

Teste de sanidade: as duas receitas somadas batem com a receita via CRM

receitaRecuperada + receitaRecorrente = receitaCRM do mesmo período

Se você já calcula receitaCRM somando amount de Conversões (veja Receita, ticket médio e cupons), essa igualdade é um bom teste de sanidade da sua integração: se não bater, o período usado nas três chamadas provavelmente é diferente.

Autenticação

API

CRM do parceiro

Métricas prontas

Casos de uso

Clientes recuperados e receita recorrente