There should be an "is_pooled" key with a Boolean value, and a "pool_id" key with its respective value. Otherwise its impossible to tell if a post is part of a pool or not based on the data that the API returns.

Surely this information isn't that hard to come by on the server side. As the pool that a post belongs to is displayed on the web page for that post already.

Posts can be in several pools at once. Just have it return an array of pool IDs, which is empty if the post isn't in any pools.

That's fair.

bump? this would be really useful...

Fisk24 said:
bump? this would be really useful...

...you just bumped a 1 day old thread. Give the admins some time will ya.

This is something that would have to be measured carefully before being implemented. The way that pool post assignments are stored doesn't lend itself well to mass fetching. It works okayish for single posts because there is only going to be one post to look up, but it tends to blow up a bit more for many posts. I may experiment with adding it as an optional piece of information the way typed tags are now.

neat, sorry i'm new to forums

I suppose its worth noting that my use case does closely mirror the web sites use case. If I had some way to execute a post-pool look up using the post's id, then that would also be ok. Although, based on your previous response that might weigh heavily as well. Especially for users whose use case revolves around spamming api calls

any progress?

Fisk24 said:
There should be an "is_pooled" key with a Boolean value, and a "pool_id" key with its respective value. Otherwise its impossible to tell if a post is part of a pool or not based on the data that the API returns.

Surely this information isn't that hard to come by on the server side. As the pool that a post belongs to is displayed on the web page for that post already.

Or simply pool:null or id, like with parent_id.
no need for two fields when you can check validity with one just fine.

Bump.