Review Paddle Billing subscription consistency with a Postgres cache

Quick overview

This read-only workflow compares Paddle Billing subscription data against a Postgres subscription cache using two observations taken ~10 seconds apart, then generates a private HTML report highlighting stable mismatches in status, plan, and access decisions.

How it works

1. Starts manually and loads the review configuration (demo/live mode, Paddle environment, settle window, price-to-plan mapping, and access policy rules).
2. In demo mode, loads two fictional Paddle and Postgres observations taken 15 seconds apart.
3. In live mode, validates the configuration, then fetches up to 200 subscriptions from the Paddle API and up to 200 rows from Postgres to capture the first observation.
4. Waits 10 seconds and repeats the Paddle API and Postgres reads to capture a second observation.
5. Compares Paddle subscriptions to the Postgres cache using the configured mappings, deferring records updated too recently (or with overdue scheduled changes) and keeping only discrepancies that appear identically in both observations.
6. Renders the results into an HTML report and outputs it as a downloadable file.

Setup

1. Set demoMode=true to run without credentials, or set demoMode=false and choose environment=sandbox or production in the configuration.
2. For live mode, add a Paddle API key as an HTTP Header Auth credential (Authorization: Bearer <token>) and ensure it has permission to read subscriptions.
3. Add Postgres credentials with SELECT-only access and either create a view/table named public.billing_subscription_cache or update both Postgres queries to return subscription_id, status, plan, access (boolean), and updated_at.
4. Update the pricePlans mapping to include every Paddle price ID you use and review the accessPolicy rules for active, trialing, past_due, paused, and canceled.
5. Keep both data sources under the 200-record limit (Paddle first page only and up to 200 cache rows) to avoid the workflow blocking the run.