Apple et Google transmettent les événements d’abonnement directement aux serveurs Adapty — via les App Store Server Notifications et les Real-time Developer Notifications. C’est ainsi que vous apprenez qu’un utilisateur a converti, renouvelé son abonnement ou s’est désabonné.

Pour envoyer ces événements vers des destinations tierces, configurez-les dans Adapty. Les plateformes tierces — MMPs, analytics, messagerie — ont chacune leur propre page d’intégration. Votre propre backend reçoit les événements via le webhook.

Chaque événement partage la même structure, bien que les champs varient selon le type d’événement, le store et vos paramètres. Types et champs des événements webhook documente le payload du webhook, et chaque article d’intégration documente le format reçu par la destination concernée. Statuts des événements explique comment interpréter un statut de livraison.

Exemples

La plupart des événements suivent les achats de l’utilisateur depuis le premier paiement jusqu’à l’expiration.

L’utilisateur annule pendant la période d’essai

L’utilisateur a activé un abonnement mensuel le 1er avril avec une période d’essai de 7 jours. Le 4e jour, il s’est désabonné.

Dans ce cas, les événements suivants seront envoyés :

1. trial_started le 1er avril
2. trial_renewal_cancelled le 4 avril
3. trial_expired le 7 avril

L’utilisateur annule après la conversion

L’utilisateur a activé un abonnement mensuel le 1er avril avec une période d’essai de 7 jours. Le 10e jour, il se désabonne.

Dans ce cas, les événements suivants seront envoyés :

1. trial_started le 1er avril
2. trial_converted le 7 avril
3. subscription_renewal_cancelled le 10 avril
4. subscription_expired le 1er mai

Pour une description détaillée des événements déclenchés dans chaque scénario, consultez les Flows d’événements.

Liste des événements

Vous pouvez contrôler quels événements chaque intégration reçoit. La plupart sont disponibles pour toutes les intégrations, à l’exception de trois d’entre elles :

• Access level updated ne se déclenche que si l’intégration webhook est configurée et que l’événement est activé. Il apparaît dans l’Event Feed et est transmis au webhook, mais aucune autre intégration ne le reçoit. Si l’intégration webhook n’est pas configurée ou si le type d’événement n’est pas activé, Adapty ne crée pas l’événement du tout, et il n’apparaît jamais dans l’Event Feed.
• Trial still active et Subscription still active sont des événements synthétiques, et seules certaines intégrations les reçoivent.

Le tableau suivant répertorie tous les événements qu’Adapty peut envoyer aux intégrations tierces :

Nom de l’événement	Description
subscription_started	Déclenché lorsqu’un utilisateur active un abonnement payant sans période d’essai, ce qui signifie qu’il est débité immédiatement.
subscription_active	Confirme que l’abonnement est toujours actif après l’événement subscription_started. Vous devez définir le nombre de jours entre le début de l’abonnement et cette vérification. L’événement est envoyé si l’abonnement est toujours actif, y compris lorsque l’utilisateur est entré dans un délai de grâce. Si l’abonnement a pris fin entre-temps ou si l’utilisateur a désactivé le renouvellement automatique, rien n’est envoyé et Adapty ne vérifie plus. Cet événement ne concerne que les abonnements souscrits sans essai. Un essai converti envoie trial_converted, qui ne déclenche pas cette vérification.
subscription_renewed	Se produit lorsqu’un abonnement est renouvelé et que l’utilisateur est débité. Cet événement commence à partir du deuxième paiement, qu’il s’agisse d’un abonnement avec ou sans essai.
subscription_renewal_cancelled	Un utilisateur a désactivé le renouvellement automatique de son abonnement. L’utilisateur conserve l’accès aux fonctionnalités premium jusqu’à la fin de la période d’abonnement payante.
subscription_renewal_reactivated	Déclenché lorsqu’un utilisateur réactive le renouvellement automatique de son abonnement.
subscription_expired	Déclenché lorsqu’un abonnement prend fin après avoir été annulé. Par exemple, si un utilisateur annule son abonnement le 12 décembre mais qu’il reste actif jusqu’au 31 décembre, l’événement est enregistré le 31 décembre à l’expiration de l’abonnement.
subscription_paused	Se produit lorsqu’un utilisateur active la suspension d’abonnement (Android uniquement).
subscription_deferred	Déclenché lorsqu’un achat d’abonnement est différé, permettant aux utilisateurs de retarder le paiement tout en conservant l’accès aux fonctionnalités premium. Cette fonctionnalité est disponible via l’API Google Play Developer et peut être utilisée pour les essais gratuits ou pour aider les utilisateurs rencontrant des difficultés financières.
non_subscription_purchase	Tout achat non lié à un abonnement, comme l’accès à vie ou des produits consommables tels que des pièces dans un jeu.
trial_started	Déclenché lorsqu’un utilisateur active un abonnement d’essai.
trial_active	Confirme que l’essai est toujours actif après l’événement trial_started. Vous devez définir le nombre de jours entre le début de l’essai et cette vérification. L’événement est envoyé si l’essai est toujours en cours. Si l’essai a pris fin ou a été converti entre-temps, ou si l’utilisateur a désactivé le renouvellement automatique, rien n’est envoyé et Adapty ne vérifie plus.
trial_converted	Se produit lorsqu’un essai se termine et que l’utilisateur est débité (premier achat). Par exemple, si un utilisateur a un essai jusqu’au 14 janvier mais est débité le 7 janvier, cet événement est enregistré le 7 janvier.
trial_renewal_cancelled	Un utilisateur a désactivé le renouvellement automatique de l’abonnement pendant la période d’essai. L’utilisateur conserve l’accès aux fonctionnalités premium jusqu’à la fin de l’essai, mais ne sera pas débité et ne commencera pas d’abonnement.
trial_renewal_reactivated	Se produit lorsqu’un utilisateur réactive le renouvellement automatique de l’abonnement pendant la période d’essai.
trial_expired	Déclenché lorsqu’un essai se termine sans être converti en abonnement.
entered_grace_period	Se produit lorsqu’une tentative de paiement échoue et que l’utilisateur entre dans un délai de grâce (si activé). L’utilisateur conserve l’accès premium pendant cette période.
billing_issue_detected	Déclenché lorsqu’un problème de facturation survient lors d’une tentative de débit (par ex. solde insuffisant sur la carte).
subscription_refunded	Déclenché lorsqu’un abonnement est remboursé (par ex. par le support Apple).
non_subscription_purchase_refunded	Déclenché lorsqu’un achat non lié à un abonnement est remboursé.
access_level_updated	Se produit lorsque le niveau d’accès d’un utilisateur est mis à jour.

Événements synthétiques

La plupart des événements sont déclenchés par un changement — un achat, un renouvellement, une annulation. Les événements Trial still active et Subscription still active fonctionnent à l’opposé. Vous définissez un minuteur. Lorsque ce minuteur expire, Adapty vérifie le statut de l’essai ou de l’abonnement. Si l’essai ou l’abonnement n’a pas pris fin, Adapty déclenche l’événement correspondant.

Ces événements synthétiques sont disponibles pour Adjust, Amplitude, AppMetrica, AppsFlyer, Branch, Facebook Analytics, Firebase, Mixpanel, OneSignal, PostHog, Singular, SplitMetrics, et le webhook. Vous devez les activer manuellement.

Si l’utilisateur désactive le renouvellement automatique avant l’expiration du minuteur, Adapty annule l’envoi. Il considère l’utilisateur comme parti, même si son accès court jusqu’à la fin de la période payée.

Désactiver l’événement empêche Adapty de démarrer de nouveaux minuteurs. Les minuteurs déjà en cours s’exécutent jusqu’à leur expiration, de sorte qu’une destination peut continuer à recevoir l’événement pendant toute la durée du délai que vous avez configuré.

L’essai est toujours en cours

• Intégration : AppsFlyer
• Événement : Essai toujours actif
• Délai : 3 jours
• Début de l’essai : 1er avril
• Fin de l’essai : 7 avril

AppsFlyer reçoit :

1. trial_started le 1er avril
2. trial_active le 4 avril
3. trial_converted le 7 avril

À noter :

• Comme il s’agit d’un essai converti, vous ne recevez jamais d’événement subscription_active.
• Si le délai avait été fixé à 7 jours, trial_active ne serait jamais arrivé. L’utilisateur avait déjà converti à ce moment-là.

L’abonnement est toujours en cours

• Intégration : Webhook
• Événement : Abonnement toujours actif
• Délai : 7 jours
• Début de l’abonnement : 1er avril, sans période d’essai
• Renouvellement : 1er mai

Le webhook reçoit :

1. subscription_started le 1er avril
2. subscription_active le 8 avril
3. subscription_renewed le 1er mai