I currently use OAuth to link Patreon accounts to my website accounts via my old backend. I have a token updater that updates the saved user tokens shortly before they expire. This works.
As I am currently building a new backend I thought about simplifications. It would be easier to use OAuth just for linking the accounts (simple table myUserId<=>patreonId) and then do everything else with a service user from the backend (eg using the clientId / clientSecret).
I did some tests today with the npm library pateron-api.ts and I can easily retrieve everything I need but I need the Creator Tokens to get the data (clientid and secret don’t seem to be sufficient).
Am I correct in understanding that everyone that has access to the cleintid and secret also has access to the creators access and refresh token? (eg via Platform | Applications | Patreon )
If yes, I guess the client id/secret should be sufficient to authorize a request for a campaign of the creator that the clientId belongs to, right?
But I find no information about such service users in the documentation.
**If service users are not possible: **
Using the normal creator tokens from Platform | Applications | Patreon seem not to be possible, as they change when I logout/login (there are multiple posts in this forum regarding this behavior). Can I use an OAuth Flow similar to the one I have built for users to get ‘creator’ tokens that don’t change when I login? Then I would at least only have to refresh one token instead of tokens for all my members (same amount of backend code but less data in DB).
I honestly don’t understand the strategy behind making the API usage so difficult while providing almost no support or updates. I’m sure the company realizes how problematic this is for developers, and I’d love to understand the reasoning behind this approach.
Am I missing something obvious? Is there perhaps another, more active forum elsewhere? The lack of activity here doesn’t seem to match the prominence of patreon as a platform. If you have any insights—even if they seem obvious to you—please let me know.
Update / Answer to my own question: My primary goal was to simplify token management (using a single service account/token instead of managing tokens for every single website user).
The Problem: As discussed in various posts, creator tokens are unreliable for service-level access because they tend to change arbitrarily (e.g., upon creator login).
My Solution:
I created a dedicated patreon user solely to manage my OAuth clients (one per stage). Based on my research, the issue with unreliable tokens doesn’t seem to occur when the ‘Creator’ and the ‘Client Owner’ are different accounts.
I use a Creator OAuth flow to obtain service-level tokens. These tokens have the permissions required to read my campaign and member data. Since I only need one “service creator,” this flow only triggers if no token exists in my database.
For actual users, I still use a User OAuth flow to identify them, but I only store their patreon_user_id and member_id. I do not store their OAuth tokens. Instead, I retrieve all necessary data using the service-level token mentioned above.
It works. I gained simplicity as i don’t need a token update process per user. So the goal is reached. It was worth the extra research if it works reliably. Time will tell.
Am I correct in understanding that everyone that has access to the cleintid and secret also has access to the creators access and refresh token? (eg via Platform | Applications | Patreon )
If yes, I guess the client id/secret should be sufficient to authorize a request for a campaign of the creator that the clientId belongs to, right?
client id and secret is not sufficient to access the APi.
Creator token is the right approach, I’m not aware of reasons why a creator token would reset. In the past these tokens had relatively short expiry, but that’s not the case anymore - this might be the reason for older posts. Login / logout should not reset creator tokens.