Currently the API is singularly focused on offering integrations for Creators. For Patrons, there’s nothing at all.
I’d really like to see an API that allows me to:
List the Creators I follow
List my Creators’ posts, comments on those posts and make comments and likes on those posts
View and compose messages
Just off the top of my head.
Looking at the web console and Android app requests, it’s very clear the API I want exists but it seems you’ve deliberately made it difficult to access.
Some potential use cases for this might be integrating Patreon with other social networks like Twitter and Mastodon, for example in the open source Twidere app.
This functionality already exists within the API, although I think you need to have a multi-creator client for it to work. @LiraNuna would know for sure.
You can pull a list of all of a user’s (yours, in this case) pledge with the current_user call. You’ll definitely want to cut down on the data it pulls using field parameters and includes, otherwise the data load can get out of hand.
Unless the docs are out of date, there’s only user -> campaign -> pledges. Notably, there’s no user -> pledges relationship, just pledges -> user. There’s also no messaging, posts or comments.
Normally, I believe the pledges will only contain pledges to the campaign that the client is associated with. Howeve, if it is a multi-creator campaign, it will list all pledges that the user has made.
As far as messaging, posts, or comments, I don’t believe that there is support for viewing them yet, and there is no support for posting any data to Patreon, as far as I am aware.
Good observation, and accurate on all counts. I see that exposing user-focused API resources would enable a bunch more use cases and things that people could build.
The quick answer is that we’re not planning to make those publicly available in the near term, through our developer-facing API.
Now for the longer answer and thinking behind that…
The main use case/question we want to answer with our API right now is “is this patron entitled to this thing” where those things live on other sites rather than Patreon’s content. It may be weird to hear this since it’s atypical for companies in our space, but strategically speaking, we’d actually be totally cool with it, as a company, if our creators posted and engaged patrons anywhere on the web rather than on Patreon itself.
As a team we’ve decided to focus our efforts on better answering the “is this patron entitled to this thing” question rather than expand the API’s surface area. We’ve gotten a lot of very good feedback (especially in this community!) on how to make our current use cases better and why we should prioritize that.
Whew. Alright. All that said… I’d still love to know the use cases you’re thinking about and how this would work in an application. Would love to learn more.
As a team we’ve decided to focus our efforts on better answering the “is this patron entitled to this thing” question rather than expand the API’s surface area.
I understand that and it’s a great goal, it’ll be cool if one day I can get Patreon content through Steam or something like that.
That said, looking through the requests in the network tab of my browser’s developer tools while browsing the site, it looks like the API I need is already there. Once I have a session cookie, I can use it all I like. It works, it responds, I can do what I like with it. It looks pretty much like the existing API but with some extra resources and fields and a really hacky authentication method.
What’s to stop you from just switching it on? Is it more engineering work than it seems? Are you worried about the extra work that might follow from it?
All that said… I’d still love to know the use cases you’re thinking about and how this would work in an application. Would love to learn more.
I have a few use cases:
Aggregating Patreon content with all my other feeds (RSS, Twitter, Facebook etc. etc.) - Patreon doesn’t have new content often enough for me to browse to it manually. Email notifications kinda work but they often get lost in the deluge of other nonsense that pours into my inbox. I’d rather have Patreon content available amongst other things I read. An API lets me build an RSS feed to integrate into my reader, pull directly into my open source Twitter/Facebook/Mastodon client or set up my own push notifications.
Preserving all my Patreon rewards - I follow a number of artists who post high resolution art, WIPs and tutorials. Past rewards are inaccessible due to being kept in ZIP files, sent as messages, just being impossible to find due to a creator having so many or because I’ve stopped supporting a creator. An API would allow me to preserve my rewards and organise them in an easy to use way.
Simply making life better. An open API would make it possible for the open source community to come up with improvements, use-cases and things neither of us have even thought of yet.
Thanks for writing those out. The first makes sense, the second hits home, and the third I very much believe in on principle alone.
What’s to stop you from just switching it on? Is it more engineering work than it seems? Are you worried about the extra work that might follow from it?
Alas. There’s no easy way to answer that briefly except saying yeah, focus as a principle. From my experience and those of people working on APIs at other companies, when it comes to this stuff and doing right by developers, there’s rarely such a thing as “just switch it on” that won’t bite us in the ass later or set us up to be unfocused/do a bad job on the main use cases we want to enable.
Little bit of thread necromancy here, but, this is the exact feature I’m looking for. I’d like to put in a vote to see a patron’s “stream” API endpoint added, like the existing internal one. Is there any chance of this happening?
If it’s really not going to happen, then I want to know, will I get in trouble for using the existing (internal) /api/stream endpoint in my application?
My use case is, I have an application that aggregates media from my subscriptions on a few different websites, and I’d like to add Patreon as a source plugin.
I have been manually browsing my Patreon stream to view content, but I keep missing things, when I don’t notice a post has attachments, or there is embedded media “under the fold” of the post. Also, main post images have long, random file names that don’t relate to the original file name of the image, but the /api/stream endpoint does actually contain the original file name. When saving media, I’d like to preserve the file name.
And yes, my paid content streams are separate from my free/public content streams, so I don’t end up accidentally posting paysite content somewhere.