We’re rewarding the question askers & reputations are being recalculated! Read more.
7

Every response from the API can be cached for up to a minute, so making the same request multiple times in that time-frame typically won't return different results. We make note of this in the throttle documentation: While not strictly a throttle, the Stack Exchange employs heavy caching and as such no application should make semantically identical ...


4

It's mentioned under the Safety section of the filters documentation that by default all response data can be safely inserted into HTML, which is why the data is pre-escaped in this case. You can try creating an unsafe filter using the unsafe parameter to use if you wish to avoid this conversion.


3

The link is correct. The purpose of that control is to provide a URL to the doc page with all the parameters prefilled. This is what most users expect and is similar to how that link control works on the rest of Stack Exchange. To get a direct link to the API, click on the link next to the Run button: This has a URL like: https://api.stackexchange.com/2....


3

The comments are more or less correct; caching applies to the /events endpoint just like every other method. This is by design for now. We have looked at differing caching policies for /events and /inbox/* routes, as the minute lag on those methods is a bit heavy handed; though we still need to protect ourselves from abusive requests.


2

You should be using min and max here if you want tags that were active in that range. fromdate and todate always apply to creation. https://api.stackexchange.com/2.0/tags?min=1322697600&max=1325116800&order=desc&sort=activity&inname=java&site=stackoverflow returns {"items": [{"name":"java-2d", "count":241, "is_required":...


2

From the docs: Searches a site for any questions which fit the given criteria. (emphasis mine) The searches on the API aren't guaranteed to exactly replicate the current on-site search, so this behaviour is expected. This may change in some future release of the API, but the current behaviour is closer to the old on-site search approach, which only ever ...


1

Notifications typically contain links within their bodies. They're considerably more free-form than inbox_items, in that they're not typically attached to a post. Notifications only even have directly attached posts (at time of writing) in the bounty and edit cases. Note that if there's a post_id present, you can query /posts/{ids} to get a link. ...


1

Tag wikis, their editing, and the promotion there of are still being actively developed (after something of a lull). I didn't think it appropriate to expose suggested edits w.r.t. tag wikis at this time accordingly, this will be revisited in the next API revision.


1

The /search/excerpts route looks to be about as good as /search and it does return both questions and answers, and it does have an answers parameter. This route is "★ All new! For version 2.2! ★"


Only top voted, non community-wiki answers of a minimum length are eligible