Patreon API v1 är avstängt – integrationer måste byta resursmodell

Patreons API-referens anger att anrop till publika API v1 slutade fungera den 7 oktober 2026 och att integrationer behöver migrera till API v2. Undantaget gäller den som begärde och fick förlängning i tid: åtkomsten kan då fortsätta längst till den 20 januari 2027. Samma tidplan gäller de äldre webhookarna för pledges. För ett eget medlemsregister innebär migreringen att den gamla resursen pledge ersätts av member, med andra fält för status, betalning och rätt till medlemsnivåer.

Ett inlägg i Sideloadlys forum beskriver hur Patreon-inloggningen lyckades men hämtningen av en pledge misslyckades efter avstängningen; Sideloadlys konto uppgav att orsaken var Patreons avstängning av v1-anrop och att felet hade rättats på deras server. Det är ett enskilt rapporterat fall, men det visar en viktig skillnad för kreatörer med egna flöden: en fungerande inloggning säger inte att medlemsuppgifterna fortfarande når tjänsten.

De anrop och webhookar som slutade fungera

Avstängningen omfattar v1-anrop under /api/oauth2/api/, oavsett om de skickas via patreon.com eller den äldre värden api.patreon.com. Även en klient som registrerats för v2 kan fortfarande anropa en v1-adress. Utvecklaren behöver därför se vilka adresser tjänsten faktiskt använder för aktuell användare, kampanjer, kampanjens pledges och inlägg. En kontroll av enbart klientens registrerade version räcker inte för att hitta de kvarvarande anropen.

De äldre utlösarna pledges:create, pledges:update och pledges:delete upphörde också enligt avstängningens tidplan. Här finns en namnskillnad i Patreons dokumentation: migrationsöversikten skriver pledge:create, pledge:update och pledge:delete i singular, medan den detaljerade listan över äldre utlösare och ändringsloggen använder pledges:* i plural. För en befintlig integration är namnen i den faktiska webhook-konfigurationen därför viktiga att kontrollera. Om medlemsregistret uppdateras enbart genom de gamla händelserna kan nya eller ändrade medlemskap utebli där även när andra delar av tjänsten fungerar.

Från pledge till member, anrop och fält för fält

En ny sökväg är bara den första delen av bytet. Resurserna nedan är Patreons angivna motsvarigheter; efter adressbytet måste kod som läser svaret anpassas till v2:s fält och relationer:

• Aktuell användare: /api/oauth2/api/current_user ersätts av /api/oauth2/v2/identity. Begär de användarfält och medlemsrelationer som flödet behöver.
• Kampanjer: /api/oauth2/api/current_user/campaigns ersätts av /api/oauth2/v2/campaigns. Kontrollera även vilka kampanjrelationer som tidigare följde med svaret.
• Medlemslista: /api/oauth2/api/campaigns/{campaign_id}/pledges ersätts av /api/oauth2/v2/campaigns/{campaign_id}/members. Det nya svaret innehåller member-resurser, inte gamla pledge-poster.
• Inlägg: /api/oauth2/api/posts/{post_id} ersätts av /api/oauth2/v2/posts/{post_id}. De fält som används för ett eget innehållsflöde behöver begäras uttryckligen.

En member är posten för en användares medlemskap i en kampanj och kan bestå över flera betalningsperioder. Ett gammalt pledge-id bör därför inte automatiskt behandlas som ett nytt member-id. När äldre registerposter kopplas om behöver utvecklaren kontrollera vilken Patreon-användare och kampanj varje post avser, så att historik och aktuell åtkomst inte blandas ihop.

• Status: Det äldre pledge-fältet status kan inte ersättas ordagrant med ett enda nytt betalningsfält. member har patron_status samt last_charge_status och last_charge_date för den senaste debiteringen.
• Belopp: Det gamla amount_cents anges i valutan som medlemmen använde. currently_entitled_amount_cents beskriver i stället beloppet för den aktuella medlemsrätten, medan campaign_lifetime_support_cents avser totalt betalt belopp i kampanjens valuta.
• Nivå och förmån: Den äldre relationen reward behöver mappas mot currently_entitled_tiers när flödet avgör vilka nivåer medlemmen för närvarande har rätt till.
• Identitet: email kan saknas om medlemmen begränsat delningen. full_name kan vara tomt eller null om medlemmen dolt sin identitet; ett sådant svar är inte i sig bevis för ett misslyckat API-anrop.

I API v2 måste vanliga attribut och relationer begäras med fields och include. Utan dem kan ett giltigt svar innehålla resursens typ och id men ändå sakna uppgifterna som behövs för ett åtkomstbeslut. Medlemslistan använder dessutom markörbaserad paginering: om klienten inte följer nästa markör i meta.pagination.cursors.next kan en del medlemmar saknas i det lokala registret.

Behörigheter och webhookar styr vad som når flödet

Migrationen kräver en ny v2-klient och mer detaljerade OAuth-behörigheter. För en kampanjs medlemmar används campaigns.members; e-post kräver dessutom campaigns.members[email] och adresser campaigns.members.address när adressuppgifter finns. identity.memberships gäller en användares egna medlemskap. Utvecklaren behöver jämföra behörigheterna som klienten begär med dem som kreatören faktiskt har godkänt.

Webhookar har också fått nya namn och nytt innehåll. members:pledge:create, members:pledge:update och members:pledge:delete gäller ändringar i pledges, medan members:create, members:update och members:delete gäller medlemsrelationen. En gratis medlem eller någon som löser in ett gåvomedlemskap utlöser inte members:pledge:create. Mottagaren måste därför läsa member-resursen i den nya payloaden och välja händelser utifrån vilka förändringar som ska påverka åtkomst och förmåner.

Vilka uppgifter en webhook levererar beror på dess behörigheter. En webhook utan campaigns.members får inte medlemsdata i payloaden, och utan campaigns.members[email] får den inte medlemmens e-post. För en tredjepartsklient knyts dessa behörigheter till den senaste token som kreatören har godkänt för klienten. En mottagen händelse med för lite data kan alltså kräva ändrade OAuth-behörigheter och ett nytt godkännande, inte bara en ändring i koden som tar emot händelsen.

Det här bör en kreatör be utvecklaren redovisa

Den användbara leveransen är en kontroll av hela kedjan mellan Patreon och den egna tjänsten. Be om konkreta svar för följande delar, med exempel från det befintliga medlemsflödet:

1. Vilka anrop går fortfarande till /api/oauth2/api/ eller api.patreon.com/oauth2/api, och vilket v2-anrop ersätter vart och ett?
2. Vilka fields- och include-parametrar begär klienten för medlemsstatus, betalinformation, aktuella nivåer och de personuppgifter som tjänsten faktiskt använder?
3. Vilka OAuth-behörigheter har klienten och varje berörd kreatör godkänt? Kontrollera särskilt medlemslista, e-post och eventuell adress samt om ett nytt godkännande behövs.
4. Vilka webhook-utlösare är aktiva, vilka member-fält finns i deras payload och hur hanteras betalda, gratis, bortskänkta, ändrade och avslutade medlemskap? Patreons webhookportal kan skicka testpayloadar till mottagaren.
5. Läser tjänsten alla sidor av medlemslistan, och stämmer dess beslut om åtkomst med medlemmens aktuella status och currently_entitled_tiers?

Patreons hjälpcenter för API:t anger att vanlig utvecklarsupport inte längre erbjuds och hänvisar till dokumentation och utvecklarforum för teknisk hjälp; fel kan fortfarande anmälas till supporten. För kreatören är den avgörande kontrollen att en medlemsändring faktiskt når det egna registret och ger medlemmen rätt åtkomst. En beviljad förlängning skjuter upp avbrottet, men lämnar den kontrollen kvar inför den slutliga avstängningen.

Läs också:

• Safello öppnar krypto-API för företag – kunden måste ändå KYC-prövas
• Egen reklam måste märkas – även när influencern äger varumärket
• Brave eller Firefox: integritetsskyddet skiljer sig mellan mobil och dator