7

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 all. The exact rules for calculating accept rate are subject to change, but currently documented here. The API returned accept rate should always match the ...


7

Oy, that was an annoying one. Subtle, as the bug only happened when you're not logged in but would be automatically logged in when you visit stackexchange.com. The actual root cause was just over-encoding a url.


6

For /sites (and only it) I have removed the pagesize constraint. I believe in this case it makes sense, since applications are expected to query all of that data and cache it for long periods of time. The constraint remains elsewhere, as it's very important for performance reasons.


6

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.


5

the original question was apparently for V1. in V2 we now have https://api.stackexchange.com/docs/required-tags the request: https://api.stackexchange.com/2.0/tags/required?order=desc&sort=popular&site=stackapps will return required tags


5

This was fixed in the latest deploy.


5

I don't know for sure what the original problem was, but the most recent issue was a result of implementing a new badge without rebuilding the API. Once the API was pushed to production, the bug was resolved. If it happens again (especially if there's a new badge) please let me (or really any employee) know. We can contact a developer directly. From a ...


5

Recently the user name truncation issue has been fixed in the Stack Apps site, now it is looking good. Screenshot for reference:


4

I believe this was related to some other throttle/quota bugs that have been recently fixed. Basically, some networking assumptions were incorrect and alot of apps ending up appear to be coming from the same IP.


4

When this class of error is encountered, the number of seconds until the quota rolls over is indicated as part of error_message now. For example: { "error_message": "too many requests from this app/user pair, more requests available in 76400 seconds" } This is meant for debugging and development purposes only, applications should take care to not actually ...


4

These typos were fixed in the latest build.


4

This will be fixed in the next build.


4

Tricky. This was a consequence of the API misinterpreting a normalized field used elsewhere in the system to indicate whether or not a post has upvoted answers. Everywhere else, "is answered" is true if either of the following are met: The question has an accepted answer The question has an answer with a score > 0 The API wasn't doing the "or" check. ...


4

The flag I think you're referring to was a recommend closure flag, which results in the post going to the Close Votes queue – not the actual flag queue, which currently has no backlog. Our flag response time is pretty good at the moment, sitting at a little under two and a half hours. It had recently been even better than that recently, but I've ...


4

If you have TamperMonkey installed, this simple script should fix the problem: // ==UserScript== // @name SAHPA (Stack Apps Home Page Aligner) // @namespace http://tampermonkey.net/ // @version 0.1 // @description Aligns the user names on the StackApps Home Page // @author anonymous2 // @match http://stackapps.com/ // @grant ...


3

The API now responds with the following headers: HTTP/1.1 200 OK Server: nginx/0.7.65 Date: Fri, 20 Jan 2012 18:53:44 GMT Content-Type: application/json; charset=utf-8 Connection: keep-alive Cache-Control: private Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, POST Access-Control-Allow-Credentials: false Content-Length: 12345 Since we ...


3

Related tags were one of the "maybes" slated for API V2.0. It got implemented today. Note that our definition of related is pretty much "appears on the same questions as", there's no real secret sauce there.


3

A fix for this has been deployed. The error was in updating the throttle after the access token was invalidated, so now the token lives on from the perspective of the request making it until it completes. It is, however, destroyed immediately from the perspective of any other requests at the time.


3

This was fixed in the most recent deploy. The tick spacing should be saner now, and the total statistics are now downloadable as well.


3

The documentation was confusing there, event_id is the question/answer/etc. id. I've modified the documentation for the event type.


3

DNS went wonky on our end, this has been fixed, those responsible have been beaten. While there's a chance it still won't resolve for some folks, all that should shake itself out within the next 15 minutes or so.


3

This should be fixed now. Really fun set of bugs there actually. In the API we delegate most tag operations to a couple (conceptually) external services, there was a dodge bit of logic in building the request w.r.t. min/max creation dates. However, fixing that revealed another more pervasive bug around date precision. Most of the API, and the backing ...


3

Found it, fix has been deployed. There was a bit of confusion around loading tag data*, basically trying to get the "required", "mod only", and "sponsored" tags for api.stackexchange.com... which doesn't end well. *Data necessary for rendering revisions that have the [tag:name] markdown extensions.


3

This should be fixed as of the latest build. Default tag wikis are a bit special behind the scenes, and the API simply wasn't looking for them at all.


3

The documentation was updated sometime in the last 2 years and the API docs (version 2.2) now state that the property may be absent:


3

This has been fixed with the latest deploy. There was a bug introduced in our move to elastic search where min/max was applied after paging results, instead of before. This meant that in any question that would typically have a lot of out-of-range results, the first page would tend to be culled down to nothing.


3

Fun one. Changes behind the scenes to how closed reasons are handled caused the API to stop getting a real reason and start getting a null one. This was just different enough from failing to get a reason that it went unnoticed, oy. This was fixed in the most recent build.


3

Update: Per Kevin Montrose's answer and its comments: The bug has now been fixed and the is_answered property will return true if either of these is true: The question has an accepted answer The question has an answer with a score > 0 To detect just whether a question has an accepted answer, merely check that the accepted_answer_id property is present and ...


3

We moved from nginx to HAProxy for our SSL provider this weekend as part of a larger rollout. In the move, we shifted our header checks to the now de-facto standard SSL protocol header. While I thought I fixed all the apps relying on the old header and standardized everything internally, stackexchange.com was left out and thought your auth requests weren't ...


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