Integração de afiliados RevenueCat: o guia completo.

Por que o webhook é a fonte de verdade

Um programa de afiliados paga dinheiro de verdade, então o gatilho da comissão precisa ser algo que nem o dispositivo do cliente nem o criador consigam forjar. O webhook da RevenueCat tem exatamente as propriedades certas:

• É de servidor para servidor. Os eventos nascem no backend da RevenueCat depois que ela validou a transação subjacente da loja. Nada no binário do seu app consegue forjar um.

• Já cobre as duas lojas. Um único webhook carrega os eventos de assinatura de iOS e Android num formato só, então a camada de afiliados não se importa de qual loja veio o recibo.

• Carrega subscriber attributes. Esta é a dobradiça da integração toda: pares chave-valor arbitrários que você define num usuário viajam com cada evento sobre esse usuário.

No InfluTo, este é um dos dois caminhos de verificação suportados — o outro é a validação direta App Store Server API / Google Play para apps sem RevenueCat. Você escolhe exatamente um por app, nunca os dois: duas fontes de verdade para o mesmo dinheiro é como nascem os bugs de dupla contagem.

Como a atribuição viaja no webhook

Passo a passo pela vida de um usuário indicado:

1. 1

   O código chega ao SDK. Um criador compartilha seu código. O usuário instala seu app e o código chega ao SDK — digitado, ou carregado pelo link de indicação.

2. 2

   O SDK marca o usuário na RevenueCat. O SDK do InfluTo o grava como subscriber attribute influto_code na RevenueCat. A partir daí, a identidade do criador viaja com o usuário dentro da própria RevenueCat. Os cliques no link do criador já foram deduplicados e marcados contra fraude do lado do InfluTo; o casamento do código, por sua vez, é determinístico — sem fingerprinting, sem IDFA, sem prompt de ATT.

3. 3

   O webhook dispara; a conversão é criada. Quando o usuário assina, a RevenueCat valida a transação da loja e dispara o webhook. O InfluTo lê o influto_code do evento, casa o criador e cria a conversão.

Os três eventos que importam

• INITIAL_PURCHASE. A primeira transação de assinatura do usuário. Ela cria a conversão e trava a taxa de comissão: a taxa no início da assinatura é a taxa por toda a vida daquele assinante, então mudanças de taxa no meio da campanha nunca reprecificam silenciosamente os assinantes existentes de um criador. Um detalhe crítico: cheque o period type do evento. Um início de teste também chega como INITIAL_PURCHASE, e um teste não é receita — nenhuma comissão acumula sobre ele.

• RENEWAL. O motor recorrente. Cada evento de renovação adiciona um acúmulo de comissão para o criador casado. É aqui também que um usuário de teste vira comissionável: quando o teste converte para pago, a transação paga aparece e a comissão começa. A regra que mantém tudo honesto é simples — a comissão segue o dinheiro verificado, então criadores ganham em conversões de teste, nunca em inícios de teste. Isso também significa que criadores não conseguem farmar comissão gerando cadastros de teste descartáveis, o que protege seu orçamento e seus dados.

• CANCELLATION. O mecanismo de honestidade. Auto-renovação desligada significa que as renovações param de chegar, e o acúmulo para com elas. Um reembolso significa que dinheiro sobre o qual você foi cobrado em comissão reverteu — por isso o InfluTo retém a comissão durante a janela de reembolso antes de ela se tornar pagável. A retenção faz com que uma assinatura reembolsada simplesmente nunca seja paga; você não corre atrás de um criador por dinheiro que já saiu. (Eventos de expiração fecham o ciclo quando o acesso realmente termina.)

Configuração, em quatro passos

1. 1

   Instale o SDK e defina o atributo. Swift, Kotlin, Flutter ou React Native/Expo — open source em github.com/influto, uns 5 minutos. O SDK cuida de gravar o influto_code; você só passa a ele o código com que o usuário chegou. Snippets exatos por plataforma: docs.influ.to/integrations/revenuecat.

2. 2

   Adicione o webhook na RevenueCat. No painel da RevenueCat, adicione o InfluTo como integração de webhook com sua URL de endpoint e header de autorização. A RevenueCat suporta múltiplas integrações de webhook por projeto, então seus webhooks existentes continuam funcionando intocados. Trate o header de auth como segredo; o InfluTo rejeita eventos não autenticados, e você pode rotacionar o segredo se vazar.

3. 3

   Teste no sandbox. A RevenueCat marca cada evento com o ambiente, então compras sandbox são distinguíveis das de produção. Rode seu app com uma conta sandbox da loja, aplique um código de indicação de teste, complete uma assinatura sandbox e veja a conversão atribuída aparecer. Se você conectou um agente de IA via MCP, o influto_integration_status reporta exatamente o que a plataforma já viu — atividade do SDK, eventos de webhook, conversões de teste atribuídas — e o influto_test_integration roda a checagem ao vivo. Não pule isto: um programa silenciosamente quebrado no dia do lançamento queima uma confiança dos criadores que você não recupera.

4. 4

   Entre no ar. Abasteça a carteira pré-paga (reembolsável, via Stripe), crie a campanha, convide criadores. Daqui em diante o pipeline é autônomo: eventos chegam, comissão acumula, o Stripe Connect paga os criadores da carteira mensalmente com mínimo de $20. Configuração grátis, taxa de plataforma de 10% sobre a receita atribuída.

claude mcp add --transport http influto https://influ.to/mcp

O que você não precisa mudar

Nada na sua configuração existente da RevenueCat se move. Entitlements, offerings, paywalls, seus webhooks atuais e análises — tudo intocado. A RevenueCat continua sendo sua fonte de verdade de receita; a camada de afiliados é um subscriber attribute mais um consumidor adicional de webhook. Se um dia você removê-la, apaga a integração de webhook e as gravações do atributo, e sua stack de assinaturas fica exatamente como era. O resumo mais curto, em nível de produto, vive na página do recurso de integração RevenueCat, linkada abaixo — e você pode configurar grátis hoje.