I've been looking into how to use the API to find out what pools an image is in. As far as I can tell, however, there doesn't seem to be a proper direct way to do it...

• The Post List doesn't include what pools an image is in. Post Show is just a single element from the list, so it doesn't include them either.
• The Pool List allows you to search for pools with a specific name, which isn't helpful if you don't know it.
• An image's pools are listed on the HTML Post Show.

... which leaves two options...

• Scrape the HTML page of every post you want to check. Because the Post List API doesn't even specify whether an image is in a pool (despite specifying whether an image has children, comments, and notes), there's no way to filter out unpooled posts ahead of time. Incredibly inefficient, which is why we have an API to use instead.
• Query the ID of every single pool, 20 at a time (no limit parameter). Query the posts in every pool, 24 at a time (no limit parameter). Requires an excessive number of individual requests, many of which will return nothing but chaff.

It seems like there ought to be a more efficient way to get the pools you actually want. Is there something in the API I'm missing? Is it really this much trouble?

It kinda makes me wish there was just a convenient dump of pool info... but e621 doesn't release database dumps, right?

There doesn't seem to be a documented way of doing it properly.

You could do a search for "inpool:true id:123456" to find out if post #123456 is in a pool. If it is in a pool, you could find out which pool it's in by searching "pool:XXXX id:123456" for each pool ID. Still kind of a kludge.

Honestly the pool system search-wise is a total mess and needs to be updated.

I've added a post's pools to post/show/x.xml and .json in the next update (in a few days or less hopefully). It'll look like this:

/post/show/12345.json:

{
  "id": 12345,
  "tags": "some tags go here",
  ...
  "pools": [
    {
      "id": 17,
      "name": "First Pool",
      "description": "Post #12345 is in this pool",
      "post_count": 1,
      "user_id": 2083,
      "created_at": 1369501084,
      "updated_at": 1377289620,
      "is_active": true,
      "is_public": true,
    },
    {
      "id": 18,
      "name": "Second Pool",
      ...
    }
  ],
  ...
}

On a related note I also added a comma-separated list of child post IDs if the post has children, and in addition to the plain list of tags, an array which contains each tag, its post count, and its type (artist, species, etc.).

tony311 said:
I've added a post's pools to post/show/x.xml and .json in the next update (in a few days or less hopefully).

Geez, I wasn't expecting a developer to pop up and add what I was looking for. Thanks!

I'm curious, though - post/index and post/show currently return the same data for each post, but the extra things added with this update will only be added to post/show, correct? Would we be able to get something in post/index like "is_pooled" (similar to has_comments, has_children, etc.) to know which posts need to be individually queried for their pools?

tony311 said:
On a related note I also added a comma-separated list of child post IDs if the post has children, and in addition to the plain list of tags, an array which contains each tag, its post count, and its type (artist, species, etc.).

It sounds like the intent is to get the API's post/show to return the same data available through the normal HTML page. I'd like to see the number of times a post has been favorited in there (though the full list of favorers seems a bit excessive). Some people might also be interested in the comments, which the API doesn't currently seem to provide in a useful fashion.

Since this is practically an API wishlist at this point... what are the odds of eventually getting convenient access to tag aliases through the API? tag/index doesn't provide them. They're listed on a tag's wiki page, but wiki/show seems to throw a "missing template" exception, and probably wouldn't include the extra tag-specific info anyway.

Viousthoneo said:
I'm curious, though - post/index and post/show currently return the same data for each post, but the extra things added with this update will only be added to post/show, correct?

Both pages use the same code to generate each post's JSON/XML so pools will show up for both.

Viousthoneo said:
It sounds like the intent is to get the API's post/show to return the same data available through the normal HTML page. I'd like to see the number of times a post has been favorited in there (though the full list of favorers seems a bit excessive). Some people might also be interested in the comments, which the API doesn't currently seem to provide in a useful fashion.

I'll look into adding API access for comments, tags, etc. soon. Generally, if there's no API for part of the site, it's because it was forgotten/hasn't been added yet, rather than we don't want to.

Viousthoneo said:
Since this is practically an API wishlist at this point... what are the odds of eventually getting convenient access to tag aliases through the API? tag/index doesn't provide them. They're listed on a tag's wiki page, but wiki/show seems to throw a "missing template" exception, and probably wouldn't include the extra tag-specific info anyway.

Shouldn't be too hard to add those at some point, maybe soon. But yeah, ideally you could get any information through the API than you could from the HTML version.

TonyLemur said:
I've added a post's pools to post/show/x.xml and .json in the next update (in a few days or less hopefully).

What happened to this feature?

(See also https://e621.net/forum/show/219320)

Safo said:
What happened to this feature?

(See also https://e621.net/forum/show/219320)

It has not been implemented yet.