Confused about the timing of updating patron_status

My current business scenario is as follows:

  • Creating webhook to listen to members:pledge:create, members:pledge:update, members:pledge:update
  • Users pay monthly in Patreon
  • Webhook receives patron_status = active_patron
  • Users cancel in Patreon
  • Webhook receives patron_status = active_patron
  • [Unable to confirm] One month later, webhook receives patron_status = former_patron

While reading the documentation at API Reference, I noticed that the patron_status field is described as “One of active_patron, declined_patron, former_patron. A null value indicates the member has never pledged. Can be null.”

Except for the last step, all other steps meet my expectations. So I am wondering if patron_status will change to former_patron after one month, and whether the webhook can notify me of the status change correctly.

If you are using only webhooks, you will need to calculate the expiry of access based on when the entitlements expire as sent in the former_patron webhook. Or you can also implement a cron that regularly syncs your campaign. Also if patrons are logging into your app/site, you could augment this with calls to /identity endpoint to get entitlements when a patron logs into your site.

Thank you for your enthusiastic help. Since the website went live, we have had real users who have unsubscribed, but we have not received any callbacks with patron_status = former_patron. So, I would like to ask:

  • What does this status mean, and when will it be synchronized to us through the webhook?
  • I did not find the “entitlements expire” attribute in the webhook test data or real purchase data. The closest attribute in terms of time is the next_charge_date field, but this field does not match the business meaning. Can you tell me which object’s attribute it specifically belongs to?

Have you created webhooks with members:create , members:update, members:delete triggers? patron_status should relate to the member, not the member’s pledge.

Currently, the webhook events I have created are “members:pledge:create”, “members:pledge:update”, and “members:pledge:delete”. Therefore, I will never receive a webhook callback with patron_status = former_patron.

To receive the webhook callback when a subscription expires with patron_status = former_patron, all I need to do is add “members:update” to the webhook event listener. Is my understanding correct? Are there any other boundary cases to consider?

Do try creating and testing hooks with members:create , members:update, members:delete and let me know the results.

I have received quite a few callbacks with the status of declined_patron now, but I haven’t received any callbacks with the status of former_patron yet. I think we may need to wait for about a month after the user’s subscription expires to receive an update with this status.

There are also some boundary cases that are difficult to test for proper behavior or require a long time to wait and track data, such as:

  • Is it possible for a user to subscribe first, then cancel their subscription and delete their membership? In this case, all user statuses received in webhooks should be active_patreon, but will members:update still be sent normally when the user’s subscription expires after a month?