Patreon API v1 Retired: Membership Webhooks Need Rework

Patreon retired public API v1 endpoints and deprecated pledge webhooks on October 7, 2026, while creators granted an extension can retain legacy access through January 20, 2027, under its API migration notice. Creator tools that still call the old routes or subscribe to pledge events need v2 endpoints, OAuth scopes and webhook handlers that understand member records.

Brad Guigar also described the legacy API as retired in an October 8 account. For a developer auditing an integration, the decisive evidence is its actual request path and webhook subscription: a client registered as “v2” can still call a retired v1 route. An approved extension applies to legacy access for that creator; it does not convert old requests or event handlers to v2.

Which v1 requests need a new route?

The old endpoint family uses /api/oauth2/api/; v2 resources use /api/oauth2/v2/. The largest change for membership tools is the replacement of the pledge resource with the member resource, which represents the relationship between a patron and a creator. Code that stores pledge IDs or reads pledge amounts to decide access must account for the new record and its fields.

GET /api/oauth2/api/current_user → GET /api/oauth2/v2/identity for the user associated with the OAuth token.
GET /api/oauth2/api/current_user/campaigns → GET /api/oauth2/v2/campaigns for campaigns owned by the authorized user.
GET /api/oauth2/api/campaigns/{campaign_id}/pledges → GET /api/oauth2/v2/campaigns/{campaign_id}/members for a creator’s membership list.
GET /api/oauth2/api/posts/{post_id} → GET /api/oauth2/v2/posts/{post_id} for an individual post.

The member resource offers patron_status, last_charge_status and currently_entitled_amount_cents. Its currently_entitled_tiers relationship identifies the tiers available to a member and can be included when fetching a member list or an individual member. The member ID is distinct from the associated user ID, so a follow-up request to /api/oauth2/v2/members/{member_id} must use the member ID.

How do pledge webhooks map to member events?

The deprecated pledges:create, pledges:update and pledges:delete subscriptions map to members:pledge:create, members:pledge:update and members:pledge:delete, respectively. The replacement events deliver a member resource rather than the old pledge payload. A handler that changes only its subscribed trigger names will still parse the wrong object.

The broader members:create, members:update and members:delete triggers cover changes to the membership relationship. Members:update includes payment charging changes, while members:delete applies when a membership without a prior payment is removed; the end of a paid pledge can instead appear as a member status update. Members:pledge:create does not fire for a free member or a redeemed gift, and members:pledge:delete does not cover cancellation of a free or gifted membership.

Those distinctions determine which events an access-control tool needs. Listening only for pledge creation can miss a free membership; treating every cancellation as a member deletion can miss a paid member’s changed status. The X-Patreon-Event header identifies the trigger, and X-Patreon-Signature lets a receiver verify the message with its webhook secret. Payload data is limited by the scopes assigned to the webhook, so an event may arrive without an email address that an older handler expects.

Scopes, fields and pagination affect the data returned

API v2 requires a new v2 OAuth client with granular scopes. The old users scope corresponds to identity for profile data, plus identity[email] when email is needed; pledges-to-me corresponds to identity.memberships. Campaign access uses campaigns, while reading a creator’s members requires campaigns.members. Member email and address require campaigns.members[email] and campaigns.members.address where applicable, and managing webhooks through the API requires w:campaigns.webhook.

Authorization alone does not populate a v2 response. A resource returns its type and ID without attributes unless the caller selects fields; related resources require include and their own field selections. A successful response lacking a name, status or tier can therefore result from the request parameters. Even when full_name is requested, it can be null if a member has chosen to hide their identity.

Member lists use cursor pagination. A request can set page[count], then pass meta.pagination.cursors.next from the response as page[cursor] on the next request; the list ends when that next cursor is null or absent. Clients that stop after the first page risk leaving members out of a local access list. Brackets in field and pagination parameter names also need URL encoding when the HTTP client does not handle it automatically.

The PHP package and extension require separate checks

The Patreon-maintained PHP client repository warns that its GitHub 1.0.0 code targets API v2 and is incompatible with old v1 calls, while the Packagist 0.3.x release remains v1-only. The newer code also removes the Art4 JSON library. A Composer dependency named patreon/patreon does not establish which API an application uses: its installed version and outgoing requests both matter.

A migration audit needs to cover each failure point: live calls to /api/oauth2/api/, subscriptions to pledges:* events, parsing of member payloads, authorized scopes, requested fields and relationships, and traversal of every member-list cursor. It also needs the creator’s extension status; a v2 client label or a PHP package name cannot establish that legacy traffic remains available.

For creators with approved extensions, the old paths and triggers remain a temporary bridge. When that access expires, membership updates will depend on the replacement routes and member events being in place.