Search Results

The tagged parameter to /search and related methods is an OR. This query will return questions tagged c# or java, for example. Or is rather expensive, which is one (of the many) reasons those method …

API V2 did this, we send down: Access-Control-Allow-Credentials: false Access-Control-Allow-Methods: GET, POST Access-Control-Allow-Origin: * With every response.

The problem with this isn't so much the security (though that's a concern), it's that we don't want the backwards compatibility constraints such blessed installations imply on our HTML and javascript. …

This is by design, for reasons of technical limitations. Unfortunately, we don't have easy access to display names at a "network level". What's available (and what's backing the API) is very normali …

You've got this all backwards. Something being suitable for use on the sites is the first (not last) step in proving it's viable for inclusion in the API. The difference is, if something isn't working …

I'll slot this in for v2.1, not super useful in general but definitely interesting information that we should make available.

This was dropped intentionally. The problem is that maintaining this sort of meta-api is both intensive (lots of v1.1 was spent not breaking v1.0 because of the way introspection was working) and of …

I don't follow, for date times the most recent date is the largest date. Sample return by events { "event_type": "question_posted", "event_id": 9369546, "creation_date": 1329777738 }, { "eve …

All write access is deferred until a future release, V2.0 is just adding authentication (and more read-only stuff, naturally).

You shouldn't be making more than 4 requests in this case. fetch a page of /users/{ids}/timeline group the ids by type (question, answers, comments) since the max pagesize fo users/{ids}/timeline i …

So... no, I'm status-declined-ing this. Fetching that sort of data for each tag on each question becomes unpleasantly slow when you're dealing with batches of questions (which most request are). How …

All numbers sent to the API as parameters are whole integers, this is made explicit in the Numbers documentation page now. It has always been explicit in terms of parameter validation in the console, …

The shallow_user type contains only fields that are "fast" to fetch, as it's always returned as a member of other (potentially expensive to fetch) types. Accordingly, we can't add any fields to shall …

Whelp, that was an oversight. accept_rate should now be returned on both user and shallow_user. Note that when insufficient data is available to calculate an accept rate, we don't return anything at …

Categories aren't sufficiently stable to expose in the API. It is entirely possible (even likely, in my opinion) that we'll revisit and rework the proposal categorization significantly in the coming …