# How to Automate Patreon Pledge Tracking using the API

- Tool: API Automations
- Difficulty: Intermediate
- Fix time: 60 minutes
- Compatibility: Patreon API v2 — campaigns.members and w:campaigns.webhook scopes
- Last updated: May 2026

## TL;DR

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.

## 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

## 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.

---

Source: https://www.rapidevelopers.com/api-automations/how-to-automate-patreon-pledge-tracking-using-the-api
© RapidDev — https://www.rapidevelopers.com/api-automations/how-to-automate-patreon-pledge-tracking-using-the-api