All I need is to keep track who joins, updates, and deletes their membership and which specific tier

API Feedback Docs Feedback
1

I want to use Patreon to deliver premium benefits to Discord servers with my bot. The simpler the setup, the better. However, from all the webhook tests, I couldn’t find a single consistent way to identify what specifically triggered the event (whether they joined, updated, or removed their membership), nor the specific membership tier in question. I guess I can solve the first issue by separating them into their own webhook endpoints, but that sounds a lot like a workaround than a solution…

I’ve also noticed that the only webhook endpoints the documentation covers are the ones that are also marked as deprecated in the developer portal, and the other 6 that are implied replacements have no documentation from what I’ve found, and manually reading through the data they send sent me to an endless rabbit hole because of how identical they all look… Like seriously, the only difference between members:create, members:update and members:delete is the gender being a 0 or a 1…

I’m new to Patreon webhooks, and I’d like to be able to rely on it exclusively if possible without any additional API requests from my end. So, I guess I have several questions that need answers.

  1. How do I identify whether a patron joined, updated, or removed their membership from the campaign?
  2. If they joined or updated their membership, how do I identify which specific tier they joined or updated to?
  3. What is an overall consistent setup for all this? My initial expectation is that “create” is when someone joined a membership, “update” is when they switched to a different tier or probably also updated their own user information, and “delete” when they leave the membership. Reading the findings from this fella makes me think it’s all much more complicated than it seems…
  4. If using the deprecated events the answer, for how long are they still safe to use? I’d rather future-proof my project whenever possible, which also includes avoiding using legacy technologies.

There are still so many things I have issues with the Patreon’s API overall that I cannot come up and write it here right now.

Anyway, I appreciate any help you may have. Thank you in advance.

2

I’ve just noticed that you can distinguish events with the X-Patreon-Event header. I want to apologize because this post was written in the middle of my frustration, and it’s quite unusual for me to work with headers.

Although, my point still stands. Please take this as nothing more than a critical feedback: the Patreon API is so far the worst API I’ve had to work with. It feels incomplete and poorly documented, and gives an overall feeling that the department working on it is underfunded, especially since the best source of information are the community forums rather than official documentation.

1 Like
3

The pledge related ones now have members: in front of them, other than that they are the same triggers:

https://docs.patreon.com/#triggers

My initial expectation is that “create” is when someone joined a membership, “update” is when they switched to a different tier or probably also updated their own user information, and “delete” when they leave the membership

members:pledge related triggers should be enough for your use case.

4

I am in a similar boat with @Deivedux. I pretty much just need to keep track of who is currently a member and what tier they are in. What appears to be a common and basic use case. If their card declines, they change tiers, they cancel their membership, etc. — I would like to know.

To be put as simply as possible;

Is this user currently paying me or not, and should they continue receiving the rewards for their tier, whichever one that may be?

@codebard states in this current thread, members:pledge triggers should suffice for this use case, which makes logical sense. However, I, like @Deivedux, have also stumbled across the thread of the poor soul who manually tested all the events — which seem to contradict the advice given in this thread. I would hate to have paying customers subscribe, only to realize I have been listening to the wrong event for the wrong scenario, and now I have no record of their existence outside of Patreon.

I have no problem using many webhook endpoints to listen to exactly what I need. The issue that I have is that the official documentation for the webhooks is at best unorganized and at worst misleading. I have spent a good few hours researching these webhooks and am yet to find answers to most of my questions. For example, what counts as a “pledge update”? Do I need to mark a member as having received their reward? Can I do it programmatically?

The sample webhook data differs wildly from the output from the webhook test outputs, and yet the test outputs are all nearly identical to each other. All the example data that us developers can get our hands on also has most of the information null’d out with hard to find explanations of their values. For example, who knew the Member resource is the data.attributes object in the webhook JSON?

This entire experience has been very frustrating and has me second guessing my intention to do business with Patreon. These aren’t the kinds of things that can be tested or YOLO’d in production.

To sum it up, I am looking for a webhook event, or (preferably) multiple events, that can tell me:

  • User (new/old/ancient) has started their subscription
  • User has changed their subscription tier
  • User has stopped their subscription (voluntarily or not)

Or put even more simply:

Is this user (still) paying me?

Now imagine my surprise when I find out pausing a pledge is a thing, and it is seemingly undocumented and without a webhook event.

5

I have just viewed the official libraries for the Patreon API. The JS, Python, and Ruby libraries haven’t been touched in 6 years. The Java library seems to have been officially abandoned, and the PHP library has similar levels of inactivity. It appears that @phildini, maintainer of many of these libraries, no longer works at Patreon.

In fact, taking a look at the introduce yourself post, it appears most of the staff are no longer working at Patreon. Like @tal (product manager), @telaviv (senior engineer), @drk (engineering manager), @nsethi (new product manager), and quite a bit of the rest of the team (with some profiles deleted). @codebard appears to be the last one still active on this forum. All of this doesn’t instill much confidence in the future of Patreon.

Along with official developer support being cut, has all support for developers just been abandoned?

I hope my frustrations and concern are made obvious from my two posts without coming off as just rude — that is not my intention. I would like to use Patreon, in theory it is a great service, but it isn’t being made easy. I currently have to struggle to split my income with you.

6

members:create and members:* related hooks should reflect you member status changes. When a new member signs up from scratch (who has never been a member), create should trigger. Delete should trigger upon cancellation. update should trigger upon any change of info on the member, including subscription renewals.

For pledges members:pledge:* hooks do the same with the same logic.

and the PHP library has similar levels of inactivity… All of this doesn’t instill much confidence in the future of Patreon.

Libraries other than PHP are not maintained at the moment. Not all current Patreon staff who work on the api related things post at the forum. The PHP lib is up to date and provides all the examples and and some directly usable code for quickstart. The api is used widely, internally and externally. The documentation is slated for an update.

7

For pledges members:pledge:* hooks do the same with the same logic.

This sentence feels like a dangerous oversimplification to me. Something the official documentation takes to the extreme. So are you telling me that the members:pledge:* triggers do the exact same as the members:* triggers? What is the point of having two differently named triggers that operate the exact same? Do you mean that the members:pledge:* triggers operate similarly — in that they also fire on create, delete, and update… but for pledges?

The definitions given in the documentation just are not that helpful. What happens if their credit card declines? They never explicitly updated their pledge, they also didn’t delete the pledge. Is it still “a member updat[ing] their pledge” if they never took any action? Can I assume then that members:pledge:update will fire if any of the returned data changes at all? This documentation seems almost a placeholder due to how vague it is — like it was for internal use, and doesn’t at all consider how those without insider knowledge and consumers of the webhooks would be using them.

image
image1648×204 19 KB

The documentation desperately needs to define some terms like “member”, “pledge”, etc. For example, it is pretty easy to see how someone could assume that a “member” is someone that is subscribed to one of their tiers — but it appears that if someone even just follows your page, they are considered a member. It also flip-flops between using “reward” and “benefit” in many places:

image
image1359×326 21.1 KB

Libraries other than PHP are not maintained at the moment

A simple notice of this in the repositories and in the documentation is a lot better than just silent abandonment. Otherwise, people are left wondering.

Not all current Patreon staff who work on the api related things post at the forum

Understandable, I probably wouldn’t want to answer questions regarding the documentation on here all day either — especially if I weren’t even allowed to prioritize improving the documentation, if that is the case. Simply improving the API would be an obvious priority, although, I am not sure much progress has been made on that either. The documentation looks nearly exactly the same as it did almost 4 years ago, except for fields being ordered alphabetically — oh, and the support email being removed. So either the API has not changed or the documentation has not been updated in 4 years? Perhaps Patreon laying off 17% of employees has hindered its ability to support users of the platform. I don’t need the actual implementor of the webhooks to speak with me, but having a few support staff to monitor this forum and provide some answers would be good.

The PHP lib is up to date and provides all the examples and and some directly usable code for quickstart

This is mentioned nowhere. If Patreon is happy with their PHP library, I see no reason to not advertise it as a source for examples. There also hasn’t been a release in nearly 5 years, but I guess the API hasn’t been updated since then either?
image

The documentation is slated for an update.

Glad to hear. It seems many years overdue. It has been my experience that providing solid and clear documentation saves plenty in support for the documented features. If things were defined clearly once, they wouldn’t need to be clarified every week here in the forum. I have been left with a bunch of questions after reading the documentation — they should provide some good direction for what needs improving.

8

So are you telling me that the members:pledge:* triggers do the exact same as the members:* triggers? What is the point of having two differently named triggers that operate the exact same?

A member’s pledge being processed also reflects on the members’ membership record. Its not something that is a miss or dangerous. You are expected to check for the type of event and the payload details on your side before processing them. There are creators who use only member related triggers to get the member info and process their rewards through them, there are those who use only the pledge related triggers and there are those who use both for different reasons. Your use case depends on your specific campaign and rewards that you have in your remote app/site.

The definitions given in the documentation just are not that helpful. What happens if their credit card declines? They never explicitly updated their pledge, they also didn’t delete the pledge. Is it still “a member updat[ing] their pledge” if they never took any action?

The webhooks send the relevant resources that are listed in the api documentation when they get triggered. On your side the thing that you should be watching for should be looking for the event type and the details of the resources that are sent to your side more than a webhook triggering. The resources sent will have the details that you need to use on your side to process whatever necessary. There is no need to say that the processing should be idempotent and also it should check whether a specific, unique webhook with unique payload has already been processed.

There also hasn’t been a release in nearly 5 years, but I guess the API hasn’t been updated since then either?

Unsupported changes to the api are not reflected in the documentation or in the supported libraries. For the rest, backwards compatibility is observed to protect remote integrations from breaking. The library and the api are both up to date and widely used, including by very large organizations, so you also can use them without hesitation.

Thanks for the rest of your feedback. Some of them are already in the backlog, and some of them arent priorities at the moment. Keeping following this forum and the dev api channel in Patreon discord are good for getting informed about any changes and new information regarding the api.