Patreon API v1-ն անջատվեց․ հին webhook-ները կարող են այլևս չաշխատել

Patreon-ի պաշտոնական API տեղեկանքի համաձայն՝ 2026 թվականի հոկտեմբերի 7-ին դադարել են աշխատել Public API v1-ի հին endpoint-ներն ու pledges:* webhook-ները։ Մինչև այդ օրը երկարաձգում ստացած ինտեգրացիաները կարող են հին տարբերակն օգտագործել մինչև 2027 թվականի հունվարի 20-ը։

Փոփոխությունն ազդում է այն ինտեգրացիաների վրա, որոնք դեռ հարցում են ուղարկում հին հասցեներով կամ սպասում են հին pledge ազդակներին։ Եթե կայքում Patreon-ով մուտքը կամ անդամակցության կարգավիճակի թարմացումը խափանվել է, պետք է առանձին պարզել օգտագործվող հարցման հասցեն և գրանցված webhook-ի անունը. հաջող OAuth մուտքը դեռ չի նշանակում, որ անդամակցության փոփոխությունները հասնում են կայք։

Ինչպես ճանաչել ազդված ինտեգրացիան

Հին API-ի որոշիչ նշանն իրական հարցման հասցեն է։ Կոդում, հավելման կարգավորումներում կամ HTTP մատյանում փնտրեք patreon.com/api/oauth2/api կամ api.patreon.com/oauth2/api ճանապարհը։ API v2-ի ռեսուրսները գտնվում են /api/oauth2/v2/ ճանապարհի տակ։ OAuth client-ի գրանցման տեսակը միայնակ բավարար չէ. նույնիսկ v2 client-ը կարող է շարունակել կանչել հին endpoint, եթե այդ հասցեն մնացել է ինտեգրացիայի կոդում։

Այս տարբերությունը վերաբերում է և՛ օգտատիրոջ հաշիվը կայքի հաշվին կապող հոսքին, և՛ արշավի անդամներին կամ հրապարակումներին դիմող սերվերային հարցումներին։ Webhook-ի դեպքում ստուգման առարկան ընդունող հասցեին գրանցված trigger-ն է՝ pledges:create, pledges:update կամ pledges:delete։ Հին ազդակի դադարելու դեպքում կայքի պահպանած անդամակցության կարգավիճակը կարող է չհամընկնել Patreon-ում կատարված նոր փոփոխության հետ. կոնկրետ հետևանքը կախված է կայքի՝ մուտքի իրավունքը թարմացնելու կանոններից։

Առանձին դեպք է Patreon-ի WordPress հավելումը։ Բրեդ Գիգարը հոկտեմբերի 8-ի հրապարակման մեջ հայտնել է, որ պաշտոնական հավելումը հոկտեմբերի 6-ին ժամանակավորապես հեռացվել էր WordPress.org-ի գրացուցակից՝ վերանայման սպասումով։ Հեռացման պատճառը չէր հրապարակվել, իսկ դրա կապը API-ի անջատման հետ հաստատված չէր։ Հավելման՝ գրացուցակում չերևալը ինքնին չի ցույց տալիս, թե դրա ներսում որ API ճանապարհն է օգտագործվում։

Որ endpoint-ներն ու webhook-ները փոխարինել

API v2 տեղափոխումը միայն հասցեի տարբերակի համարը փոխելը չէ։ Հին pledge ռեսուրսին փոխարինում է member ռեսուրսը, ուստի պետք է վերանայել նաև պատասխանի դաշտերը, նույնացուցիչների մշակումը և անդամակցության կարգավիճակից կախված գործողությունները։ Հիմնական endpoint-ների համադրությունը հետևյալն է.

• /api/oauth2/api/current_user → /api/oauth2/v2/identity՝ մուտք գործած օգտատիրոջ համար։
• /api/oauth2/api/current_user/campaigns → /api/oauth2/v2/campaigns՝ ստեղծողի արշավների համար։
• /api/oauth2/api/campaigns/{campaign_id}/pledges → /api/oauth2/v2/campaigns/{campaign_id}/members՝ արշավի անդամների համար։
• /api/oauth2/api/posts/{post_id} → /api/oauth2/v2/posts/{post_id}՝ հրապարակման համար։

Հին pledges:create, pledges:update և pledges:delete ազդակների համապատասխան նոր անուններն են members:pledge:create, members:pledge:update և members:pledge:delete։ Նոր webhook-ը փոխանցում է member մոդելի տվյալներ, ուստի միայն trigger-ի անունը փոխելը բավարար չէ. ընդունող կոդը պետք է կարողանա կարդալ նոր payload-ը։ Եթե հին մշակիչը փնտրում է pledge օբյեկտի դաշտերը կամ գրառումները կապում է հին pledge ID-ին, ազդակի ստացումը դեռ չի երաշխավորում տվյալների ճիշտ թարմացում։

Նոր ազդակներն էլ տարբեր իրադարձություններ են նկարագրում։ members:pledge:create-ը չի գործարկվում, երբ մարդը դառնում է անվճար անդամ կամ օգտագործում է նվեր անդամակցություն։ members:update-ը վերաբերում է անդամակցության տվյալների փոփոխություններին և ներառում է վճարման հետ կապված թարմացումներ։ Այդ պատճառով վճարովի pledge-ի ստեղծումը հետևող ինտեգրացիան և անդամակցության ցանկացած փոփոխությամբ մուտքի իրավունքը թարմացնող ինտեգրացիան կարող են տարբեր trigger-ների կարիք ունենալ։

Ինչ ստուգել OAuth թույլտվություններում և պատասխանում

API v2-ի թույլտվությունների համար հարկավոր է ստեղծել նոր v2 OAuth client։ Նախկին scope-երը պետք է համադրել տվյալների հետ, որոնք ինտեգրացիան իրականում կարդում է. նույն անվան փոփոխությունը բոլոր դեպքերում նույն ծավալի հասանելիություն չի տալիս։ Կարճ ստուգաթերթը հետևյալն է.

• Հին users-ի փոխարեն՝ identity, իսկ օգտատիրոջ էլփոստի անհրաժեշտության դեպքում՝ նաև identity[email]։
• Հին pledges-to-me-ի փոխարեն՝ identity.memberships՝ օգտատիրոջ անդամակցությունները կարդալու համար։
• Հին my-campaign-ի փոխարեն՝ campaigns՝ ստեղծողի արշավին դիմելու համար։
• Արշավի անդամների համար՝ campaigns.members, իսկ անհրաժեշտության դեպքում առանձին campaigns.members[email] կամ campaigns.members.address։
• Ծրագրով webhook ստեղծելու կամ կառավարելու համար՝ w:campaigns.webhook։

Թույլտվությունը դեռ ամբողջ պատասխանը չէ։ API v2-ում անհրաժեշտ հատկանիշներն ու կապված ռեսուրսները պետք է բացահայտ պահանջել fields և include պարամետրերով։ Առանց դրանց հարցումը կարող է հաջող ավարտվել, բայց ռեսուրսի մասին վերադարձնել միայն տեսակը և նույնացուցիչը։ Անդամի կարգավիճակն օգտագործող կոդում, օրինակ, պետք է պահանջել հենց այն դաշտերը, որոնցով որոշվում է հասանելիությունը, ապա ստուգել, թե ինչպես է մշակվում բացակայող կամ դատարկ արժեքը։

Webhook-ի payload-ը նույնպես սահմանափակվում է նրան վերագրված scope-երով։ Երրորդ կողմի client-ի ստեղծած webhook-ի դեպքում դրանք կախված են ստեղծողի տրամադրած թույլտվություններից. առանց campaigns.members[email]-ի անդամի էլփոստը payload-ում չի հայտնվի։ Եթե այդ տվյալը պետք է, անհրաժեշտ է խնդրել համապատասխան թույլտվությունն ու ստեղծողի նոր հաստատումը։ Webhook-ի scope-երը տեսանելի են Patreon-ի կառավարման պորտալում, ինչը թույլ է տալիս տարբերել թույլտվության պակասը իրադարձության առաքման խափանումից։

Տեղափոխման հերթականությունը

Անվտանգ տեղափոխումը սկսվում է հին կախվածությունների ցանկից, որպեսզի փոխարինվի և՛ տվյալներ կարդացող հարցումը, և՛ փոփոխության մասին ազդակը։ Նույն հոսքում արժե գրանցել, թե որ հարցումը կամ իրադարձությունն է փոխում կայքի մուտքի իրավունքը. այդ կապն է որոշում, թե նոր member տվյալների որ դաշտերն ու trigger-ներն են անհրաժեշտ։

1. Գտնել գործող Patreon հարցումների իրական հասցեները, գրանցված webhook-ների անուններն ու դրանց ընդունող հասցեները։
2. Ստեղծել v2 OAuth client, ընտրել անհրաժեշտ scope-երը և նոր թույլտվություններով հաստատել կապը։
3. Փոխել endpoint-ները, pledge-ի փոխարեն մշակել member ռեսուրսը և fields ու include պարամետրերով պահանջել օգտագործվող տվյալները։ Անդամների ցանկը կարդալիս վերանայել նաև page[count] և page[cursor] պարամետրերով էջավորումը։
4. Գրանցել v2 trigger-ները և կառավարման պորտալից փորձնական payload ուղարկել ընդունող հասցեին։ Ստուգել X-Patreon-Event անունը, նոր մարմնի մշակումը և X-Patreon-Signature ստորագրության վավերացումը։
5. Համեմատել նոր հոսքի արդյունքները անդամակցության ստեղծման, փոփոխման և ավարտի դեպքերում, ապա հեռացնել հին հասցեներից ու ազդակներից կախվածությունը։

Եթե webhook-ը հասնում է սերվեր, բայց անդամի տվյալը կամ էլփոստը բացակայում է, առաջինը ստուգման ենթակա են payload-ին վերագրված թույլտվությունները և կոդի՝ member կառուցվածքը կարդալու ձևը։ Եթե ազդակ ընդհանրապես չի հասնում, պետք է ստուգել գրանցված trigger-ը, ընդունող հասցեն և առաքման վիճակը։ Երկարաձգումով դեռ աշխատող հին հոսքը կարող է ժամանակավորապես քողարկել այդ խնդիրները, ուստի տեղափոխման արդյունքը պետք է գնահատել հենց նոր հարցումների և ազդակների աշխատանքով։

Կարդացեք նաև:

• Playwright թե Cypress․ արագ թեստը կարող է պահանջել նոր աշխատանքային հոսք
• Patreon-ը փակում է «վճարում մեկ հրապարակման համար» մոդելը․ վերջնաժամկետը մոտ է
• Գեղեցիկ CV-ն կարող է չանցնել ATS-ը․ սյունակներն ու աղյուսակները խանգարում են