I want to write an application for which, after some logic to select a set of questions, it would be most convenient to get the whole set of stuff at once that is normally shown on a Stack Exchange Q&A webpage (like this one):

  • the question
  • its metadata (score, dates, author, etc.)
  • its comments
  • all answers
  • all of each answer's metadata
  • all of each answer's comments

How surprised was I to find nothing like that in the API! I have looked through the Stack Apps tour, the FAQs, and of course the API documentation.

But even the most promising-looking operations come nowhere near this functionality: /questions/{ids}/answers and /questions/{ids}/comments do not, /search and /search/advanced do not, /posts and /posts/{ids}/comments do not.

What am I missing?

Or is there seriously no way to get from the API in one request what the Stack Exchange servers produce hundreds of thousands of times every day in response to a single browser-level URL request for a web page?

Of course, I could parse the HTML. But not only does that look like trouble -- it should simply not be necessary, I think.


1 Answer 1


There is indeed a way: Just use an appropriate filter with /questions or /search.

For example, you can get roughly the JSON equivalent of page How do I get a GreaseMonkey/UserScript to interact with the Live Preview? with this query:


The key is to configure the filter not only to include the /questions elements you want, but also the /answers elements and even the /comments elements. (Or just reuse the above filter.)

If in the filter's question fields you have selected answers, the API will apply the filter's answer fields to determine what answer fields to include. If in the filter's answer fields you have selected comments, the API will apply the filter's comment fields to determine what comment fields to include in the answer parts of the questions result of your /questions query. Likewise for the question's immediate comments.

So why have I not found this during my initial search for a solution? (I am answering my own question here)

Two reasons:

  • It is not enough, when assessing the /questions query type, to read the page /docs/questions-by-ids (or /docs/questions for that matter), you also need to follow the link "question objects" to get enlightened.
  • The term "filter" for the filters is misleading. "transitive results structure specifiers" would be more appropriate.

My conclusion: There is room left for improvement of the API documentation, but the API itself is quite flexible.

  • @KevinMontrose Should I combine this question and answer into a new post tagged FAQ? I tend to be a reasonably attentive reader of documentation. Commented Jan 13, 2015 at 9:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .