Off the top of my head, some of the cross post aggregation that piefed does in the web frontend was only very recently (like literally yesterday) added to the api. Post flair is another that was only just added to the api within the past week or so, so I don’t expect it has seen a lot of use yet in apps. Lots of the features around feeds and topics aren’t included yet. And, most annoyingly for me, is that most of the notification types are not returned in the api yet. So, you can end up in a scenario where the api will tell you that you have X unread notifications, but since some of those notification types might not be defined yet in the api, you can only interact with a subset of them.

We are working on it!

I think the limited part of this is that there are still lots of things that you can only do in the web ui that aren’t exposed to the api yet. It isn’t rate limited.

There is an api by which things like mobile apps can be used with piefed.

It all works (I wrote it), but that issue is about consolidating some code for the future. We know there are going to need to be some changes made to the implementation of post flair once we start testing lemmy interoperability. So, that issue is essentially saying let’s write all the flair code in one place so that it’s easier to change in the future instead of having flair code duplicated between the api side and the web ui side of the piefed.

At the moment it would not be interoperable, but that is something we are planning to change once we can start testing it. Last time I checked, the lemmy test server wasn’t yet running a build that had post flair yet. As soon as it is, we would want to make sure that Activitypub messages we send have the same structure.

Thanks, replied further up the chain.

tl;dr - flairs are not in the api yet, but I hope they will be after some tweaks in preparation for lemmy 1.0, tags aren’t either, but could probably be added without breaking anything.

That’s right. Flairs are not currently in the api (edit: tags as well, see edit at bottom). The focus on the initial api implementation was to work with existing lemmy apps/frontends, so flair wasn’t prioritized (this is also why you don’t see feeds/topics in the api except for a couple undocumented endpoints). The other docs page that Blaze linked is an ongoing rewrite of parts of the api/documentation as part of making the api self-documenting.

Now that the first pass at the api is done, it would make sense to come back and add them…however, there are changes to flair that need to happen in the near future, so I think it makes sense to hold off on adding them to the api until those changes happen. I would also want to add possible flair to community endpoints as well so that apps know what flair a new post could have.

Edit: I read too quickly and mistook flairs for tags. Everything I wrote above is accurate for flairs and is similar for tags. Tags are not present in the api at the moment, but could be added without breaking anything. It is simply a matter of prioritization. My effort at the moment is focused on the aforementioned self-documentation overhaul of the api which is what app creators said would be the most helpful to them.