Apple and Google report subscription events directly to Adapty servers — through App Store Server Notifications and Real-time Developer Notifications. That’s how you learn that the user converted, renewed, or churned.

To send these events onward, set up the destination in Adapty. Third-party platforms — MMPs, analytics, messaging — each have their own integration page. Your own backend receives events through the webhook.

Every event shares the same structure, though the fields depend on the event type, the store, and your settings. Webhook event types and fields documents the webhook payload, and each integration article documents the format that destination receives. Event statuses explains how to read a delivery status.

Examples

Most events follow the user’s purchases from the first charge to expiration.

The user cancels during the trial

The user activated a monthly subscription on April 1st with a 7-day trial. On the 4th day, they unsubscribed.

In that case, the following events will be sent:

1. trial_started on April 1st
2. trial_renewal_cancelled on 4th April
3. trial_expired on 7th April

The user cancels after converting

The user activated a monthly subscription on April 1st with a 7-day trial. On the 10th day, they unsubscribed.

In that case, the following events will be sent:

1. trial_started on April 1st
2. trial_converted on April 7th
3. subscription_renewal_cancelled on April 10th
4. subscription_expired on May 1st

For a detailed breakdown of which events are triggered in each scenario, check out the Event flows.

Event list

You can control which events each integration receives. Most are available for every integration, except three:

• Access level updated only triggers if both the webhook integration is configured and the event is enabled. It appears in the Event Feed and reaches the webhook, but no other integration receives it. If the webhook integration isn’t configured or the event type isn’t enabled, Adapty doesn’t create the event at all, and it never appears in the Event Feed.
• Trial still active and Subscription still active are synthetic events, and only some integrations receive them.

The following table lists all events that Adapty can send to third-party integrations:

Event name	Description
subscription_started	Triggered when a user activates a paid subscription without a trial period, meaning they are billed instantly.
subscription_active	Confirms the subscription is still active after the subscription_started event. You need to set the number of days between the start of the subscription and this check. The event arrives if the subscription is still active, including when the user has entered a grace period. If the subscription ended by then, or the user turned auto-renewal off, nothing arrives and Adapty doesn’t check again. This event only follows subscriptions bought without a trial. A trial that converts sends trial_converted, which doesn’t start the check.
subscription_renewed	Occurs when a subscription is renewed and the user is charged. This event starts from the second billing, whether it’s a trial or non-trial subscription.
subscription_renewal_cancelled	A user has turned off subscription auto-renewal. The user retains access to premium features until the end of the paid subscription period.
subscription_renewal_reactivated	Triggered when a user reactivates subscription auto-renewal.
subscription_expired	Triggered when a subscription fully ends after being canceled. For instance, if a user cancels a subscription on December 12th but it remains active until December 31st, the event is recorded on December 31st when the subscription expires.
subscription_paused	Occurs when a user activates subscription pause (Android only).
subscription_deferred	Triggered when a subscription purchase is deferred, allowing users to delay payment while maintaining access to premium features. This feature is available through the Google Play Developer API and can be used for free trials or to accommodate users facing financial challenges.
non_subscription_purchase	Any non-subscription purchase, such as lifetime access or consumable products like in-game coins.
trial_started	Triggered when a user activates a trial subscription.
trial_active	Confirms the trial is still active after the trial_started event. You need to set the number of days between the start of the trial and this check. The event arrives if the trial is still running. If the trial ended or converted by then, or the user turned auto-renewal off, nothing arrives and Adapty doesn’t check again.
trial_converted	Occurs when a trial ends and the user is billed (first purchase). For example, if a user has a trial until January 14th but is billed on January 7th, this event is recorded on January 7th.
trial_renewal_cancelled	A user turned off subscription auto-renewal during the trial period. The user retains access to premium features until the trial ends but will not be billed or start a subscription.
trial_renewal_reactivated	Occurs when a user reactivates subscription auto-renewal during the trial period.
trial_expired	Triggered when a trial ends without converting to a subscription.
entered_grace_period	Occurs when a payment attempt fails, and the user enters a grace period (if enabled). The user retains premium access during this time.
billing_issue_detected	Triggered when a billing issue occurs during a charge attempt (e.g., insufficient card balance).
subscription_refunded	Triggered when a subscription is refunded (e.g., by Apple Support).
non_subscription_purchase_refunded	Triggered when a non-subscription purchase is refunded.
access_level_updated	Occurs when a user’s access level is updated.

Synthetic events

Most events are triggered by a change — a purchase, a renewal, a cancellation. The Trial still active and Subscription still active events are the opposite. You set a timer. When the timer expires, Adapty checks the status of the trial or subscription. If the trial or subscription did not end, Adapty fires the corresponding event.

These synthetic events are available for Adjust, Amplitude, AppMetrica, AppsFlyer, Branch, Facebook Analytics, Firebase, Mixpanel, OneSignal, PostHog, Singular, SplitMetrics, and the webhook. You need to manually turn them on.

If the user turns auto-renewal off before the timer expires, Adapty skips the send. It counts the user as gone, even though their access runs to the end of the paid period.

Turning the event off stops Adapty from starting new timers. Timers already running still send when they expire, so a destination can keep receiving the event for as long as the delay you configured.

The trial is still running

• Integration: AppsFlyer
• Event: Trial still active
• Delay: 3 days
• Trial start: April 1st
• Trial end: April 7th

AppsFlyer receives:

1. trial_started on April 1st
2. trial_active on April 4th
3. trial_converted on April 7th

Note the following:

• Since it’s a converted trial, you never receive a subscription_active event.
• If the delay was set at 7 days, trial_active would never arrive at all. By that time, the user had already converted.

The subscription is still running

• Integration: Webhook
• Event: Subscription still active
• Delay: 7 days
• Subscription start: April 1st, without a trial
• Renewal: May 1st

The webhook receives:

1. subscription_started on April 1st
2. subscription_active on April 8th
3. subscription_renewed on May 1st

Note the following:

• The subscription must start without a trial. A converted trial sends trial_converted, which doesn’t start the timer.
• If the user turned off auto-renewal on April 3rd, subscription_active never arrives, even though their access runs until May 1st.
• The May renewal doesn’t start a second timer. You receive subscription_active once per subscription.