Skip to main content

Webhook Flow Diagram


JavaScript Implementation

Complete Webhook Handler


Quick Start

1. Set Up Webhook in RevenueCat Dashboard

  1. Navigate to IntegrationsWebhooks
  2. Click Add new configuration
  3. Set Authorization Header: Bearer MYSECRET
  4. Enter your webhook URL: https://yourdomain.com/webhooks/revenuecat
  5. Select environment (Production, Sandbox, or Both)

2. Configure Your Server

3. Deploy Webhook Endpoint

Deploy the handler to your server and ensure it responds within 60 seconds.

4. Test with RevenueCat Dashboard

Use the “Send Test Event” button in RevenueCat dashboard to verify your implementation.

Database Schema Example

Database Sync Functions


Database Schema Example


Environment Variables

Create a .env file with the following configuration:

Security Notes

Never commit these values to version control:
Use environment-specific files:
Validate environment variables on startup:

Database Schema Example


Security Best Practices

1. Always Validate Authorization

2. Respond Quickly

3. Handle Duplicates

4. Use HTTPS Only

Configure your webhook URL with HTTPS. HTTP is not supported.

5. Verify Event Structure


Testing Guide

Test with RevenueCat Dashboard

  1. Go to IntegrationsWebhooks
  2. Click on your webhook configuration
  3. Click Send Test Event
  4. Select event type
  5. Verify your endpoint receives and processes the event

Test with Sandbox Purchases

Make test purchases in sandbox environment:

Common Patterns

Sync Subscription Status

Send Email Notification

Update Analytics


Troubleshooting

Webhooks Not Received

  • Verify HTTPS endpoint is accessible
  • Check authorization header matches exactly
  • Ensure server responds within 60 seconds
  • Check RevenueCat dashboard for delivery errors

Duplicate Events

  • Implement idempotency using event.id
  • Check database for already-processed events
  • Return 200 OK even for duplicates

Missing Data

  • Use GET /subscribers API for complete data
  • Check event.entitlements for active subscriptions
  • Verify event.subscriber_attributes for custom data

RevenueCat API: V1 vs V2

RevenueCat provides two API versions for fetching customer data. Understanding when to use each is critical for building a robust subscription system.

API V1 - Subscribers Endpoint

Endpoint:
Use Cases:
  • Fetching complete subscriber information after webhook
  • Getting subscriber attributes and custom metadata
  • Historical purchase data
  • Integration aliases (multiple IDs for same customer)
Example Request:
Example Response:
JavaScript Implementation:

Endpoint:
Use Cases:
  • Real-time subscription status verification
  • Source of truth for active entitlements
  • Self-healing when webhooks fail or are delayed
  • Backup validation before granting access
Why V2 is Better for Status Checks:
  • Returns active entitlements directly
  • Cleaner, more focused response structure
  • Explicitly shows what’s currently active
  • Better for programmatic status checks
  • Includes customer attributes in paginated format
  • Provides experiment enrollment data
  • Tracks customer metadata (last_seen, platform, country, etc.)
Important V2 API Differences:
  • expires_at is returned as milliseconds timestamp (not ISO date string)
  • active_entitlements.items contains only entitlement_id and expires_at (no product_id)
  • Customer attributes (email, displayName) are in separate attributes.items array
  • No subscriptions object - only active entitlements are returned
  • Responses are paginated (though most apps fit in single page)
Example Request:
Example Response:
JavaScript Implementation:

Comparison: V1 vs V2


Working with V2 API Responses

Extract active entitlements:
Extract customer attributes:
Get customer metadata:
Get experiment enrollment:
Complete example:

Self-Healing Pattern

Use this pattern to ensure your database stays synchronized with RevenueCat, even if webhooks are missed or delayed.

The Problem

Webhooks can fail due to:
  • Network issues during delivery
  • Server downtime when webhook arrives
  • Processing errors in your handler
  • Race conditions with concurrent events
  • Webhook delivery delays (2+ hours for cancellations)

The Solution: Database + API V2 Backup

Implementation


Rate Limiting

Both V1 and V2 APIs share the same rate limit: Limit: 480 requests per minute per API key Best Practices:
  1. Cache aggressively - Store results in database
  2. Use webhooks as primary - API calls as backup only
  3. Implement exponential backoff on rate limit errors
  4. Monitor API usage - Set up alerts at 80% capacity

When to Use Which API

General Rule: Use V2 for status checks, V1 for detailed customer information.

API Endpoint Examples

Subscription Status Endpoint

Create an endpoint that clients can call to check subscription status:

Force Sync Endpoint

Create an endpoint to manually trigger sync with RevenueCat:

Check Specific Entitlement

Debug Endpoint (Development Only)

Express.js Router Example

Next.js API Routes Example


Sample Webhook Events

Understanding Event Structure

All RevenueCat webhooks follow this structure:

Key Fields to Extract

Sample: Initial Purchase

Extract:
  • User: event.app_user_id"user_123"
  • Email: event.subscriber_attributes.$email.value"user@example.com"
  • Entitlements: event.entitlements{ "pro": {...} }
  • Active: Check if entitlements.pro.expires_date > now
  • Product: event.product_id"yearly_pro"

Sample: Renewal

Action: Update expires_at to new date, keep entitlements active.

Sample: Cancellation

Important:
  • Entitlements STILL ACTIVE until expires_date
  • Update status to “cancelled”
  • Schedule access removal at expiration_at_ms

Sample: Expiration

Action: Remove all access - entitlements is now empty {}

Sample: Billing Issue

Action:
  • Entitlements STILL ACTIVE during grace period
  • Flag account with billing issue
  • Access expires at grace_period_expires_date if not resolved

Sample: Product Change

Action:
  • Update product_id to new_product_id
  • Entitlements remain active
  • Update expiration date

Entitlement Extraction Code

Common Patterns

Check if user has specific entitlement:
Check if ANY entitlement is active:
Get all active entitlement IDs:
Get expiration dates:

Entitlement Sync Strategy

Why Sync is Critical

Your database must stay synchronized with RevenueCat to provide accurate access control. Out-of-sync entitlements cause:
  • Users losing access they paid for (churn)
  • Users gaining unauthorized access (revenue loss)
  • Poor user experience
  • Support tickets

Three-Layer Sync Architecture

Sync Flow Per Webhook

Every webhook event follows this flow:

Handling Missed Webhooks

Even with webhooks, you need backup verification:

Critical Sync Points

ALWAYS sync entitlements on these events:

Example: Cancellation Sync

Example: Expiration Sync

Sync Verification Schedule

When to verify with RevenueCat API:

Monitoring Sync Health

Track sync issues in your application:

Working with Entitlements

Understanding Entitlements vs Products

Product ID = What the user purchased (e.g., “monthly_pro”, “yearly_premium”)
Entitlement ID = What access they have (e.g., “pro”, “premium_features”)
One product can grant multiple entitlements. Multiple products can grant the same entitlement.

Check User Access

Middleware for Route Protection

Frontend Entitlement Check

Entitlement-Based Feature Flags

Sync Entitlements After Webhook

Query Active Users by Entitlement

Analytics and Reporting


Additional Resources