Skip to main content
Answer

Posthog integration does not set rc_subscription_status as a user property

  • October 20, 2025
  • 3 replies
  • 57 views
T
Forum|alt.badge.img

The documentation states that the `rc_subscription_status` property should be set as a user property with each RC event that is sent to Posthog. This is not happening in our integration.

We do receive RC events, and see the property there as an event property, but the related users do not have the latest subscription status set as a user property.

Here’s a link to the relevant docs:
https://www.revenuecat.com/docs/integrations/third-party-integrations/posthog

From this page:

Whenever RevenueCat sends an event to PostHog, we'll update the rc_subscription_status user attribute with any applicable changes, using one of the following values: [...]

Best answer by hussain

Hi,

Thanks for the clear follow-up. You’re right that our PostHog integrations docs mention “Whenever RevenueCat sends an event to PostHog, we'll update the rc_subscription_status user attribute with any applicable changes…..” Docs here: https://www.revenuecat.com/docs/integrations/third-party-integrations/posthog#subscription-status-attribute

However, if you look closely at the sample payloads on that same page. You’ll see rc_subscription_status inside the properties object of each event (not under $set). That’s exactly how our integration currently behaves: we include rc_subscription_status as an event property on every RevenueCat event we send (e.g., initial_purchase, renewals, cancellations, etc.).

As of today we do not include a $set object in the event payload. Hence, If you want rc_subscription_status stored on the person, you can use a PostHog transformation (or an ingestion step in your pipeline) to copy properties.rc_subscription_status into $set.rc_subscription_status for incoming RC events. This keeps the event schema the same while making PostHog set/update the person property on ingestion.

Hope this helps. Let me know if you have any other questions. I’m happy to help.

Best,

Hussain

    This post has been closed for comments

    3 replies

    hussain
    RevenueCat Staff
    Forum|alt.badge.img+6
    • hussain
    • RevenueCat Staff
    • October 22, 2025

    Hi,

    Thanks for reaching out. I’m happy to help.

    I just checked your PostHog integration and reviewed the most recent deliveries from RevenueCat. Those requests do include the rc_subscription_status key in the payload we’re sending to PostHog, exactly as described in the docs. I’ve sent you a DM with a screenshot showing the request body so you can see the field and value as we transmitted it.

    Best,

    Hussain

    Hussain, Developer Support Engineer (RevenueCat)
    T
    Forum|alt.badge.img

    As I mentioned, and as is visible in the screenshot, the property is present as an event property. The documentation mentions that the integration is going to set it as a user property, and for that to happen the property needs to be within the `$set` object in the event properties, that contains all the properties to be set on the user profile upon ingestion of the event

    hussain
    RevenueCat Staff
    Forum|alt.badge.img+6
    • hussain
    • RevenueCat Staff
    • Answer
    • October 23, 2025

    Hi,

    Thanks for the clear follow-up. You’re right that our PostHog integrations docs mention “Whenever RevenueCat sends an event to PostHog, we'll update the rc_subscription_status user attribute with any applicable changes…..” Docs here: https://www.revenuecat.com/docs/integrations/third-party-integrations/posthog#subscription-status-attribute

    However, if you look closely at the sample payloads on that same page. You’ll see rc_subscription_status inside the properties object of each event (not under $set). That’s exactly how our integration currently behaves: we include rc_subscription_status as an event property on every RevenueCat event we send (e.g., initial_purchase, renewals, cancellations, etc.).

    As of today we do not include a $set object in the event payload. Hence, If you want rc_subscription_status stored on the person, you can use a PostHog transformation (or an ingestion step in your pipeline) to copy properties.rc_subscription_status into $set.rc_subscription_status for incoming RC events. This keeps the event schema the same while making PostHog set/update the person property on ingestion.

    Hope this helps. Let me know if you have any other questions. I’m happy to help.

    Best,

    Hussain

    Hussain, Developer Support Engineer (RevenueCat)
    Terms & ConditionsCookie settingsAccessibility statement