Subscribe to members:pledge:create, members:pledge:update, and members:pledge:delete webhook events to track new pledges, upgrades, downgrades, and cancellations in real time. In Patreon API v2, the pledge resource is deprecated — the member resource is the source of truth with currently_entitled_amount_cents, last_charge_status, and will_pay_amount_cents fields. Any tutorial using /pledges is using the dead v1 API.
| Fact | Value |
|---|---|
| Platform | Patreon |
| Rate limits | Undisclosed per-second limits; 4xx circuit breaker: 2,000 bad requests in 10… |
| Difficulty | Intermediate |
| Time required | 60 minutes |
| Last updated | May 2026 |
API Quick Reference
Undisclosed per-second limits; 4xx circuit breaker: 2,000 bad requests in 10 min = 30-min block
REST only
Patreon Pledge Tracking via Webhooks
Real-time pledge tracking uses Patreon's webhook system to receive events when patrons create, update, or delete their pledges. Combined with periodic full member syncs, this provides accurate revenue forecasting data. The member resource in API v2 replaces the deprecated v1 pledge resource — all pledge data now lives on the member object.
https://www.patreon.com/api/oauth2/v2Setting Up Pledge Tracking Authentication
- 1Create OAuth client at patreon.com/portal/registration/register-clients
- 2Request scopes: campaigns.members and w:campaigns.webhook
- 3Deploy your webhook handler to a public HTTPS URL
- 4Create webhooks via POST /api/oauth2/v2/webhooks with pledge triggers
- 5Store the webhook secret returned from creation — needed for signature verification
- 6Include User-Agent header on all API calls
Key endpoints
members:pledge:createFires when a patron creates a new pledge. Payload contains member data including currently_entitled_amount_cents.
members:pledge:updateFires when a patron upgrades or downgrades their pledge tier. Contains updated amount and tier data.
members:pledge:deleteFires when a patron cancels their pledge. The member still exists but pledge data is removed.
/api/oauth2/v2/campaigns/{campaign_id}/membersFull member sync for reconciliation — compare against webhook-tracked data to catch missed events.
Step-by-step automation
Register Pledge Webhook Events
Why: You need all three pledge events to capture the full pledge lifecycle. Missing members:pledge:update means you won't see tier upgrades or downgrades.
Create a webhook subscription for all three pledge events. Register once — events flow until you delete the webhook.
1curl -s -X POST \2 -H "Authorization: Bearer $PATREON_TOKEN" \3 -H "User-Agent: PledgeTracker (admin@yourapp.com)" \4 -H "Content-Type: application/json" \5 -d '{6 "data": {7 "type": "webhook",8 "attributes": {9 "triggers": ["members:pledge:create", "members:pledge:update", "members:pledge:delete"],10 "uri": "https://yourapp.com/webhooks/patreon/pledges"11 }12 }13 }' \14 'https://www.patreon.com/api/oauth2/v2/webhooks'Handle Incoming Pledge Webhook Events
Why: Each pledge event type represents a different revenue action — new revenue, changed revenue, or lost revenue. Routing by event type enables accurate MRR tracking.
Verify the signature and route events to appropriate handlers. Extract the pledge amounts and status from the JSON:API member payload.
1# Webhook payloads are received by your server — not curl2# Verify: MD5-HMAC of raw body against X-Patreon-Signature headerLog Pledge Changes and Update MRR Database
Why: Storing each pledge event creates a revenue history for MRR forecasting, churn analysis, and financial reporting. The last_charge_status field distinguishes paid revenue from declined revenue.
Log pledge events to a database with the member ID, event type, amount, and timestamp. Calculate running MRR from active patron amounts.
1# Not applicable — database logging done in handler codeRun Periodic Full Sync for Reconciliation
Why: Webhooks can miss events if your handler is down. A daily full member sync reconciles the database against Patreon's actual data to catch any gaps.
Compare webhook-tracked MRR against the full member sync total. If they differ by more than a small threshold, log a discrepancy alert.
1# Full sync runs as a scheduled job — not interactive curl2# Check webhook delivery status:3curl -s \4 -H "Authorization: Bearer $PATREON_TOKEN" \5 -H "User-Agent: PledgeTracker (admin@yourapp.com)" \6 "https://www.patreon.com/api/oauth2/v2/webhooks" | python3 -m json.toolComplete working code
Complete Patreon pledge tracking webhook handler. Verifies signatures, routes pledge create/update/delete events, calculates MRR delta, and logs to a in-memory store for demonstration.
Error handling
Missing fields[member]= parameters in the webhook setup, or not requesting currently_entitled_amount_cents in the include fields.
Patreon webhook payloads include whatever fields your webhook subscription is configured to return. Ensure currently_entitled_amount_cents is in the fields list when creating the webhook. If using the default webhook without field configuration, amounts may be sparse.
Missed webhook events when the handler was down, or edge cases like payment retries not triggering a new event.
Implement a daily reconciliation run: fetch all active members with currently_entitled_amount_cents and compare the sum to your tracked MRR. Update your database to match when discrepancies exceed a threshold.
Missing w:campaigns.webhook scope on the access token.
Alternatively, create webhooks manually at patreon.com/portal/registration/clients/{id}/webhooks without needing this scope. Or re-authorize your OAuth client with w:campaigns.webhook included.
The /pledges endpoint is from Patreon API v1, which is deprecated. v1 clients and endpoints are no longer maintained and will be removed.
Use /api/oauth2/v2/ prefix. In v2, pledge data lives on the member resource — use currently_entitled_amount_cents, last_charge_status, and will_pay_amount_cents fields on members. There is no /pledges endpoint in v2.
Patreon retries webhook delivery on non-200 responses. If your handler processes the event before returning 200, a timeout can cause Patreon to retry, sending the event again.
Always return 200 immediately before processing. Store processed event IDs in a database and skip duplicates.
Rate Limiting for Pledge Event Processing
| Scope | Limit | Window |
|---|---|---|
Security checklist
- Store PATREON_PLEDGE_WEBHOOK_SECRET in environment variables
- Verify X-Patreon-Signature on every incoming webhook request
- Use raw body for signature — parsed JSON changes byte content
- Return 200 immediately and process asynchronously to prevent timeout-induced retries
- Implement idempotency with a processed-events log to prevent duplicate MRR counting
- Store pledge history with event timestamps for financial audit trails
- Never expose MRR data publicly — restrict to authenticated dashboard access
Automation use cases
Real-Time MRR Dashboard
Update a live MRR counter on each pledge event. Display current MRR, new pledges this month, and cancellations in a creator analytics dashboard.
Upgrade/Downgrade Notification
Send yourself a Slack or Discord notification when a patron upgrades to a high-value tier or downgrades, with the amount change and patron name.
Churn Alert System
Track pledge deletions and calculate daily churn rate. Alert via email when monthly churn exceeds a threshold (e.g., 5% of MRR in 24 hours).
Best practices
- Never use /pledges — it's from the deprecated v1 API. Use member resource fields (currently_entitled_amount_cents) in v2
- Return 200 from webhook handlers immediately — delayed responses cause Patreon to retry, which creates duplicate events
- Handle all last_charge_status values: Paid, Declined, Deleted, Pending, Refunded, Fraud — each affects MRR differently
- Run a daily reconciliation against the full members endpoint to catch any webhook events missed when your handler was down
- Store pledge events with timestamps, not just the current amount — you'll need history for MRR trend analysis
- Use will_pay_amount_cents for forecasting next month's expected revenue — it reflects the pledged amount even if the last charge status is Pending
- Implement idempotency by storing processed webhook delivery IDs to prevent MRR double-counting on retries
Ask AI to help
Copy one of these prompts to get a personalized, working implementation.
I'm building a Patreon pledge tracking system that handles members:pledge:create, members:pledge:update, and members:pledge:delete webhooks. I verify MD5-HMAC signatures, extract pledge amounts from JSON:API payloads, and maintain a running MRR calculation. I need to add a daily reconciliation job that fetches all active members from the Patreon API and compares the sum of their currently_entitled_amount_cents to my tracked MRR. Can you help me implement the reconciliation with drift correction and alerting?
Frequently asked questions
Why is the /pledges endpoint returning 404 or empty data?
The /pledges endpoint belongs to Patreon API v1, which is deprecated and no longer maintained. In API v2, pledge data is embedded in the member resource — use currently_entitled_amount_cents, last_charge_status, and will_pay_amount_cents on the member object. Any tutorial referencing /api/oauth2/v2/pledges or /api/oauth2/api/pledges is using a dead endpoint.
What does will_pay_amount_cents mean vs currently_entitled_amount_cents?
currently_entitled_amount_cents is the amount the patron is entitled to right now — what tier they're on. will_pay_amount_cents is the projected amount for their next billing cycle, which may differ if they changed tiers after the last billing date. Use currently_entitled_amount_cents for current MRR and will_pay_amount_cents for next-month MRR forecasting.
What are all the possible last_charge_status values?
Patreon documents six values: Paid (payment succeeded), Declined (payment failed), Deleted (charge was deleted), Pending (charge is in process), Refunded (charge was refunded), and Fraud (flagged as fraudulent). Only Paid status should count toward MRR. Declined patrons should trigger win-back flows.
How do I track upgrades vs downgrades specifically?
members:pledge:update fires for both. Compare the current currently_entitled_amount_cents to the previous amount you stored for that member. If current > previous, it's an upgrade. If current < previous, it's a downgrade. Store member amounts in a database keyed by member_id to enable this comparison.
Can I track lifetime support revenue through the API?
Yes. The lifetime_support_cents field on the member object contains the total amount a patron has paid across their entire history with your campaign. This is available on webhook payloads and in the members endpoint. Useful for LTV (lifetime value) analysis and reward eligibility checks.
What happens if my webhook is down during Patreon's billing cycle?
Patreon queues webhook deliveries and retries them. When your handler comes back up, it will receive all queued events — potentially dozens in a burst at billing cycle time. This is why idempotency is critical: store processed event IDs and skip duplicates to prevent MRR being counted multiple times from retried deliveries.
How does RapidDev recommend structuring the pledge event database?
A minimal schema: pledge_events table (member_id, event_type, amount_cents, previous_amount_cents, charge_status, tier_names, timestamp) and a members table (member_id, current_amount_cents, last_updated). Run a nightly reconciliation that fetches live data from Patreon and corrects any drift. This pattern is straightforward to implement in PostgreSQL or Supabase.
Need this automated?
Our team has built 600+ apps with API automations. We can build this for you.
Book a free consultation