Webhooks general questions

Friendly Help
1

Hi!

I need some help figuring out some things about webhooks.
Well first of all, what I’m trying to achieve is to have my database to be synced with my patreon. So that I know which user has which pledge amount and whether they are active or not.
This way i can make db request on my server to determine user permissions instead of making api requests everytime i want to be sure that the user is pledging a required amount to access parts of my website.

So my question is: are webhooks the way to go here?
And if yes then i have some questions about them :smile:

  1. Is webhook response always the same regardles of which hook trigered it? (basicly an info dump about user status and his membership)

  2. Are webhooks guaranteed to be sequential. This might be a dumb one(i never used webhooks), but can hook members:update trigger before members:create on the same member?
    Or if user creates a pledge and immediately cancels is pledge:delete guaranteed to come after pledge:create? Or should i timestamp most recent change in my DB and execute change comming from the hook only if it is more recent that previous hook change?

  3. Documentation is slightly vague about what EXACTLY triggers each webhook. Like if i get a new member and have both members:update and members:create hooks set up, will they both fire? Or will i get one response only?

  4. lets say patreon changes their pledge amount, will members:update also trigger? Or only members:pledge:update?

  5. will pledge deletion trigger only members:pledge:delete or will it also trigger members:pledge:update and subsequently members:update?

  6. is members.update one-size-fits-all sort of trigger? Can i just setup hook on that trigger and be sure that i will get all the information about new patreons changes in pledges etc etc?

I would really appreciate any help!

3 Likes
2

48 hours without response oh boy. Sooo
Yesterday i did some testing to see what will trigger what and here are my results, in case someone will also need it. (to update docs for example :wink: )

  1. to answer my own question webhook response is always of the same format.

  2. now for the tests, here is the format:
    callback -> what i did -> YES/NO (yes means i got response, no means i didnt)

  • member:update -> old(canceled) patron joins(pledges) -> YES

  • member:update -> patron removes(cancels) pledge -> YES

  • member:update -> completely new member pledges -> NOOO

  • member:update -> patron ± changes pledge -> NO

  • members:create -> oldPatreon pledges again -> NO

  • member: create -> completely new member pledges -> YES

  • members:pledge:update -> existing patron ± pledge -> YES

  • members:pledge:update -> patron cancels pledge -> NOO

  • members:pledge:update -> old(canceled) patron pledges -> NO

  • members:pledge:create -> old user creates new pledges -> YES

  • members:pledge:delete -> user cancels pledge -> YES BUT still shows amount pre cancel (WTF…ok not wtf useful if you want to keep track of what pledge you just lost)

  • member:update -> patron follows even not pledging -> YES

  • member:update -> follower pledges -> YES

////////

in conclusion:

  • completely new user -> members:create (a)

  • pledge± -> members:pledge:update (b)

  • patreon removes pledge(cancels) -> member:update ( c)

  • parton rejoins -> member:update ( c)

So here you go.
It would be nice to get some confirmation from the dev support team if my findings were correct.

6 Likes
3

This is really useful information, thanks.

I have a couple of related questions about webhooks:

(i) Are there any circumstances where a single user action will trigger multiple webhooks or are the different events essentially mutually exclusive?

(ii) Does anyone know if the structure of the data sent by the “Send test” links on the following page is up to date? If not, is there any possibility it could be brought up to date as development is much more difficult if the test data is inaccurate. Forcing developers to pledge themselves to see the structure of the data is very poor practice, if that’s what is necessary.

4

Currently, using the campaings/XX/members endpoint by requesting members and pledges along with identity info as includes or relations to regularly sync your campaign to your db, and then complementing it with webhooks is the way which most creators, developers and partners approach this. It provides a regularly synced, up to date db along with instantly communicating latest changes.

  1. Any webhook response format would be the same as specified or as you receive any other webhook of the same type at your website. The same webhook would not change format depending on who or what triggered it, as long as the trigger is the same.

  2. You should not expect webhooks to be sequential. There is no guarantee that a sequentially created webhook will trigger before a webhook that was created after it, since it cannot be guaranteed that every single webhook post will succeed when tried. Anything can go wrong along the route and any webhook attempt could return a non 200 status, causing the webhook to be retried. You should consider them async and take that into account in your code.

  3. Members create should fire when a new member is created and not when an existing member is updated. Seeing members as unique relationships of unique users to your campaign would be better - when a relationship is created, the create hook fires. Others should fire when the relationship itself changes.

  4. As you already found in your test, member update relates to the updates of the member relationship. Pledges are what that unique member pay to your campaign. So pledge updates should not trigger member updates. Member update should change with change in a member resource.

  5. Deleting a pledge will alter the member status of the member in your campaign. So it should fire an update in member too. Pledge delete should also fire. However if you are a CUF campaign, deletion of a pledge does not mean that the user will (or should) lose access at that moment. The member would retain access to whatever he or she was entitled to until the current payment period expires.

  6. No its not - it should fire when the member relation of a user to your campaign changes. Pledge relationships should change by their own changes. So basically the resource hierarchy is like user → member → pledge. Creation of new pledges and deletion of pledges affect member.

It would be nice to get some confirmation from the dev support team if my findings were correct.

That looks right.

1 Like
5

A single user action should trigger the webhooks it is related to. There can be two webhooks sent in the case of any change that affects both the membership of a user to your campaign and the pledge of that member.

There can occur double posting of the same webhook for whatsoever reason since this is something that happens in between two different infrastructures with many intermediaries in between. Your app can receive the webhook but the resulting 200 response may not end up reaching Patreon. So Patreon may retry the webhook etc - anything can happen.

Your code should take that into account and implement some kind of signature to make sure that it processes a webhook only once in the case of double posting. Ie, hashing the webhook properties and then comparing it with the processed webhooks or fields that you saved into the db etc may work.

(ii) Does anyone know if the structure of the data sent by the “Send test” links on the following page is up to date?

They would be up to date but avoid using deprecated ones.

2 Likes