Adding restrictions to back-end using Webhooks.

Dear RevenueCat team and community,

I’m currently exploring the most robust and scalable approach to integrate RevenueCat into my app’s architecture, and I would greatly appreciate your insight.

Specifically, I’m looking for a way to use RevenueCat as the payment processor, while managing subscription logic and access control entirely within my own backend.

I’ve reviewed the documentation and several community examples, but I haven’t come across a setup that fully aligns with this approach. Below, I’ve outlined the different options I’ve considered — along with the challenges and trade-offs associated with each — in the hopes of receiving your feedback on what might be the most appropriate and future-proof solution.

Objective

Manage all access control and feature restrictions (e.g., premium functionality, group boosts) internally, while using RevenueCat for purchase handling and subscription lifecycle management.

Option 1: RevenueCat as the Source of Truth (via API)

This follows the conventional setup — using the RevenueCat REST API to validate subscription status on demand.

Concerns:

• For each premium-restricted endpoint, my backend would need to make an external API call to RevenueCat to validate entitlement.

• This introduces additional latency and potential performance bottlenecks.

• It also adds complexity when scaling, especially for endpoints that are frequently used (e.g., creating new objects like categories).

Option 2: Passing Subscription Data via Client Requests

Here, I’d include the user's subscription status (as retrieved from RevenueCat) in API requests — for example, passing a hasPremium: true flag from the client.

Concerns:

• This requires significant adjustments across many endpoints to accommodate and validate additional metadata.

• Trusting client-side state, even with validation, introduces risk and fragility.

• It adds implementation overhead and increases the likelihood of inconsistencies.

Option 3: Syncing Subscription Status to Backend at Key Moments

This approach involves:

• Updating the user record in my backend when a purchase is completed (client triggers a sync).

• Performing a fresh check at app launch or significant lifecycle events, updating the backend again if the subscription status has changed.

Concerns:

• This approach is relatively simple and keeps backend logic clean.

• However, it’s not reliable for time-sensitive actions like group-based subscriptions (e.g., “boosts”), where precise knowledge of expiration or renewal dates is required.

• There’s a risk of stale data if the app isn’t launched frequently or misses important subscription changes.

• Trusting client-side state, even with validation, introduces risk and fragility.

Option 4: Webhook-Driven Sync to Backend (Event-Based)

This is the most promising model I've considered.

• RevenueCat webhooks notify my backend of relevant subscription events (e.g., renewals, cancellations, expirations).

• My backend updates user and group records accordingly.

• All access control is then based on local data, which remains consistent thanks to RevenueCat’s event stream.

Advantages:

• Enables real-time updates without polling.

• Keeps subscription data under local control, ensuring fast and scalable access control.

• Supports more advanced features like group-level upgrades (“boosts”), by tracking subscription expirations internally.

Key Questions

1. Is it advisable to rely on RevenueCat primarily as an event emitter (via webhooks), while maintaining subscription state in my own database as the primary source of truth for access control?

2. Are there best practices for managing hybrid setups like this, where RevenueCat handles transactions, but business logic is managed internally?

3. In which scenarios would the RevenueCat API still be the preferred method over webhooks — for example, for verification, reconciliation, or on-demand checks?

4. Is there anything structurally flawed or risky about this webhook-centric approach in terms of long-term maintainability or alignment with RevenueCat’s intended use?

I appreciate any input the team or community can provide on this. My goal is to build a system that is both technically solid and operationally sustainable.

Thank you in advance for your time and expertise.

Best regards,