# RevenueCat + Brew

Déclenchez des automatisations Brew à partir des événements RevenueCat d’achat intégré, d’abonnement et de facturation sur Apple, Google, Amazon, Stripe et Web Billing. Nécessite l’offre RevenueCat Pro ou supérieure.

URL canonique : https://brew.new/fr/browse/integrations/revenuecat

- Sens des données : Données entrantes
- Connexion : Secret de webhook
- Achats intégrés et abonnements

## Fonctionnalités disponibles

- **Déclencheurs par événement** : Déclenchez des automatisations Brew à partir des événements RevenueCat d’achat intégré, d’abonnement et de facturation sur Apple, Google, Amazon, Stripe et Web Billing.

## Transformez vos événements d’abonnement en e-mails utiles

Connectez RevenueCat pour lancer des e-mails à l’image de votre marque quand quelqu’un effectue un achat, renouvelle ou résilie son abonnement, ou rencontre un problème de facturation dans votre app. Brew prend en charge 11 événements de cycle de vie RevenueCat, et une même séquence peut servir les abonnés App Store, Google Play, Amazon, Stripe et Web Billing.

RevenueCat et les stores restent responsables des achats, des renouvellements, des remboursements et des droits d’accès (entitlements). Brew crée et envoie les e-mails.


## Ce que vous pouvez créer

- E-mails de bienvenue pour les abonnés : l’événement INITIAL_PURCHASE est envoyé quand un nouvel abonnement démarre, y compris au début d’un essai. Les achats ponctuels arrivent plutôt sous la forme de NON_RENEWING_PURCHASE.
- Reçus de renouvellement : l’événement RENEWAL est envoyé quand un abonnement est renouvelé ou qu’un abonné dont l’abonnement avait expiré se réabonne, et il contient productId, priceUsd, pricePurchaseCurrency et currency.
- Avis de problème de facturation : l’événement BILLING_ISSUE est envoyé quand un paiement échoue. Ajoutez un lien vers la page où l’abonné peut mettre à jour son moyen de paiement.
- Relances après résiliation : l’événement CANCELLATION contient cancelReason, pour que l’e-mail puisse traiter un remboursement ou une erreur de facturation différemment d’une résiliation à l’initiative de l’abonné.
- E-mails de bon retour : l’événement UNCANCELLATION est envoyé quand un abonné rétablit un abonnement résilié avant son expiration.
- Réactivation après la fin de l’accès : l’événement EXPIRATION est envoyé quand un abonnement prend réellement fin, et il contient expirationReason.
- Avis de changement d’offre : l’événement PRODUCT_CHANGE contient previousProductId et newProductId. Le nouveau produit peut ne prendre effet que plus tard : formulez donc l’e-mail comme la confirmation d’un changement demandé.
- Avis de mise en pause et de prolongation : l’événement SUBSCRIPTION_PAUSED est envoyé quand la mise en pause d’un abonnement Google Play est programmée pour la fin de sa période. L’événement SUBSCRIPTION_EXTENDED est envoyé quand un store prolonge la période ou que Google Play reporte un prélèvement.

## Une résiliation ne signifie pas la fin de l’accès

L’événement CANCELLATION peut signaler un abonnement résilié ou un remboursement, et ne signifie pas à lui seul que l’accès a pris fin. C’est l’événement EXPIRATION qui indique la fin de l’accès. L’événement SUBSCRIPTION_PAUSED ne fait que programmer une pause à venir.

Utilisez CANCELLATION pour les e-mails de reconquête ou de questionnaire de départ, et EXPIRATION pour tout ce qui suppose que l’accès a pris fin. Un événement UNCANCELLATION n’arrête pas une exécution déjà lancée par une résiliation : vérifiez donc revenuecat_subscription_status dans une condition avant chaque e-mail suivant.

Filtrez sur environment pour tenir les événements SANDBOX à l’écart de vos automatisations actives.


## Configurer RevenueCat dans Brew

- Les webhooks RevenueCat nécessitent l’offre RevenueCat Pro ou supérieure.
- Ouvrez Intégrations, choisissez RevenueCat, puis cliquez sur « Générer l’URL de webhook ».
- Dans RevenueCat, ouvrez Integrations > Webhooks et ajoutez une configuration. Collez l’URL Brew, choisissez Production, Sandbox ou les deux, puis sélectionnez les événements de cycle de vie à envoyer.
- Activez la signature HMAC des webhooks dans cette configuration et copiez immédiatement le secret de signature : RevenueCat ne l’affiche qu’une seule fois. Collez-le dans Brew, puis cliquez sur « Connecter ». Ne collez ni une clé API REST RevenueCat, ni la valeur facultative de l’en-tête Authorization.
- Envoyez un webhook de test depuis RevenueCat. Un envoi TEST signé active la connexion, mais ne lance jamais d’automatisation destinée à vos clients.
- Renseignez l’attribut d’abonné $email pour chaque client, afin que Brew dispose d’une adresse à laquelle envoyer les e-mails.
- La connexion crée un déclencheur pour chacun des 11 événements. Il n’existe pas d’interrupteur pour activer ou désactiver un événement. Créez une automatisation, sélectionnez son événement RevenueCat et envoyez un test tant qu’elle est encore en brouillon. Seules les automatisations actives s’exécutent quand un événement correspondant arrive.

## Événements RevenueCat pris en charge

Brew prend en charge les 11 types d’événements suivants :

- INITIAL_PURCHASE
- RENEWAL
- NON_RENEWING_PURCHASE
- PRODUCT_CHANGE
- CANCELLATION
- UNCANCELLATION
- EXPIRATION
- BILLING_ISSUE
- SUBSCRIPTION_PAUSED
- SUBSCRIPTION_EXTENDED
- TRANSFER

## Synchronisation des contacts et personnalisation

Brew lit d’abord le destinataire dans l’attribut d’abonné $email, puis accepte à défaut un app user ID, un original app user ID ou un alias qui a la forme d’une adresse e-mail. Les alias RevenueCat correspondent à l’historique des app user IDs : renseignez donc $email explicitement plutôt que de vous fier à eux. Si aucun de ces champs ne contient d’adresse réelle, Brew enregistre l’événement comme non résolu, ne crée aucun contact et ne lance aucune automatisation.

Chaque événement vérifié qui contient une adresse e-mail réelle crée ou met à jour un contact Brew, identifié par son adresse e-mail, qu’une automatisation utilise l’événement ou non. Lorsque les données sont présentes, Brew renseigne revenuecat_app_user_id, revenuecat_store et revenuecat_environment.

Les événements de cycle de vie donnent à revenuecat_subscription_status la valeur active, cancelled, expired, billing_issue ou pause_scheduled. Brew enregistre aussi revenuecat_product_id, revenuecat_cancel_reason, revenuecat_expiration_reason, revenuecat_last_purchase_at et revenuecat_pending_product_id lorsque l’événement les fournit.

Pour les balises de fusion, utilisez le schéma de payload déclaré par l’événement sélectionné. Tous les événements incluent email, productId, priceUsd, pricePurchaseCurrency, currency, store, environment et createdAt, lorsque ces champs sont présents. Le champ priceUsd contient le prix en USD, et pricePurchaseCurrency le prix dans la devise indiquée par currency. Les payloads RevenueCat ne fournissent à Brew ni prénom ni nom.

Le champ store est transmis tel quel par RevenueCat, par exemple APP_STORE ou PLAY_STORE, et RevenueCat peut ajouter de nouvelles valeurs. Ciblez explicitement les valeurs qui vous intéressent.

Un achat ne vaut pas consentement aux e-mails marketing. Enregistrez le consentement séparément et vérifiez-le avant tout envoi promotionnel.


## Pourquoi TRANSFER n’envoie-t-il jamais d’e-mail ?

RevenueCat envoie TRANSFER avec des app user IDs, mais sans adresse e-mail de destinataire. Brew l’enregistre comme non résolu et ne lance aucune automatisation.


## Pourquoi un événement apparaît-il sans qu’aucun e-mail ne soit envoyé ?

Recevoir un événement et envoyer un e-mail sont deux étapes distinctes. Vérifiez qu’une automatisation correspondante est active, puis contrôlez ses filtres, son historique d’exécution, l’éligibilité du destinataire et le domaine d’envoi. Un envoi TEST ne lance jamais d’automatisation. Quand un destinataire n’est pas résolu, vérifiez d’abord $email ; Brew accepte aussi les app user IDs, les original app user IDs et les alias qui ont la forme d’une adresse e-mail.


## Limites et dépannage

- Brew ne peut ni accorder ni révoquer de droits d’accès, ni émettre de remboursements, ni modifier d’abonnements.
- Une erreur 401 avec un en-tête de signature manquant signifie généralement que la signature HMAC est désactivée ou que la valeur Authorization a été collée à la place du secret de signature. Activez la signature HMAC, copiez le nouveau secret et reconnectez RevenueCat.
- Une erreur 401 avec une signature HMAC non concordante signifie que Brew détient un secret différent ou périmé. Renouveler le secret dans RevenueCat invalide l’ancien : copiez donc la nouvelle valeur et reconnectez Brew.
- Si aucun webhook n’arrive, vérifiez que votre offre RevenueCat inclut les webhooks.
- Vérifiez le consentement et la finalité de chaque e-mail. Synchroniser vos abonnés n’autorise pas les envois promotionnels.

## Sources et guides de configuration

- [Guide de configuration de RevenueCat](https://docs.brew.new/integrations/import/revenuecat)
- [Créer une automatisation](https://docs.brew.new/create-emails/build-an-automation)
- [Balises de fusion](https://docs.brew.new/create-emails/merge-tags)
- [Ce que vous pouvez envoyer avec Brew](https://docs.brew.new/get-started/what-you-can-send)
- [Webhooks RevenueCat](https://www.revenuecat.com/docs/integrations/webhooks)
- [Attributs client RevenueCat](https://www.revenuecat.com/docs/customers/customer-attributes)

## Voir aussi

- [Toutes les intégrations](https://brew.new/fr/browse/integrations.md)
- [Inscription](https://brew.new/fr/sign-up.md)
- Site web : https://brew.new