Tag Info

Hot answers tagged

13

There is no tutorial for the API, nor is there likely to be one -- at least officially. There is a "Hello World" introduction. To use the current API (version 2.2), you really only need to know/do: How to make an HTTP GET request, in the language of your choice. There are also various user-supplied libraries in .net, PHP, Python, etc. to help with this. ...


5

This is currently not possible via the API. The best you could do is have the user logged into a browser and then screen-scrape the stackoverflow.com/users/{user_id}/?tab=votes pages... Hardly an acceptable workaround. The Authentication doc, Scope section, does say: private_info - access full history of a user's private actions on the site. ...


4

According to this answer, it looks like 100.


4

That is the 2.1 documentation, it's just the title (and perhaps the first sentence) that hasn't been updated. All of the routes added in 2.1 are there, so you don't have to worry that it's missing anything important.


4

items is documented in the Common Wrapper Object. It is an array of whichever object the given route returns. In the case of /me/associated,  items is an array of network_user objects. If you use a filter that returns .wrapper.type, then type will return the type that items has assumed. EG: { "items": [ // <=== Linked ...


4

The routes that don't link require POST requests because they create context, so there's nothing meaningful to be gained by going to those URLs in your browser. The rest of the routes return data when you send GET requests to them, which is why the link is useful in that case.


3

Well technically it already says "Most methods" so it's correct as written. But I agree, it's easy to miss that note. After the next build there will be another sentence mentioning that some methods have lower limits and their individual documentation pages will call them out (as they already do). Should be harder to miss that way.


3

The console JS was doing fuzzy matching on ?site; but that's not really correct, as you demonstrated. With the latest deploy it does an exact match if possible.


3

Are they moved to filters? Yes, you need to generate a filter that includes the question.body, question.comments, and question.answers fields. There are shorthand filters (i.e. _bca) that will do this for upgrade compatibility, but their use is discouraged and you're better off just making a filter that contains exactly what you want anyway.


3

There doesn't seem to be a place that describes the policy. That API-object, documentation page would be perfect for it. However, a lead Stack Exchange developer has stated that anything that reveals voting patterns will be hidden or private. Another Stack Exchange employee explains how user deletions and post deletions are kept private-ish, but ...


3

If this doesn't happen, this simple script will do it for you!: $('.site-picker.ui-autocomplete-input').on('input', function() { setTimeout(function() { var mylist = $('body > ul.ui-autocomplete'); var listitems = mylist.children('li').get(); listitems.sort(function(a, b) { return ...


2

A fix for this will go out in the next build.


2

Quoting the very first paragraph in the section General: Applications should be registered on Stack Apps to get a request key. Request keys grant more requests per day, and are necessary for using access_tokens created via authentication. Click the first link, and there's the registration form.


2

key is your app key, access_token identifies a user (and a set of permissions) and is what you get at the end of an authentication flow. Keys are not secret, for example here's what the Documentation Console's registration looks like: You can find your app key by going to Manage Your Applications (in the Stack Apps homepage sidebar) and selecting one of ...


2

Commercial use of the API is permitted. If you're just displaying content on a website, you should follow our attribution requirements. If you have questions about a more specific use case, feel free to contact us.


2

Technically that's incorrect. The help docs say nothing about the required/optional nature of user and owner, only whether certain of their subfields are required should they be present. This is a gap in our automagic doc generation system which will - eventually - be fixed. When it is, user and owner will be marked "optional."


2

Looks correct to me.


2

Methods now return only a single result for a given id, even if that id is found multiple times in the passed {id} field.


2

Take a look at http://api.stackoverflow.com/1.1/usage/enumerations ; which is now linked from the front page of the documentation as well. Its very simplistic, but one of the nice behind the scenes changes in 1.1 was making it a lot easier for me to update the documentation. Expect some better documentation on returned values in the not incredibly distance ...


2

This has been fixed. Going to a particular API/usage page should run requests against that API, instead of the default demonstration site (which has always been SO).


2

Annoyingly all usuage pages on all sites use the stackoverflow api site. I think Kevin said this is because changes to the API happen first on stackoverflow. (not sure why this is a problem, because the API hardly ever changes)


2

We're using number in the JSON sense of the word. number in that context does cover all the data types we're returning. I suppose it could be tightened up a bit, though... Descriptions of the types of number coming back are now part of the /help docs.


2

inname has been documented on /users and /tags now. Thanks for catching that oversight.


2

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


2

body and comments have been removed from those methods.


2

Returned parameters now have an optional field in the documentation (example) that indicates whether they should always be present. For the duration of the beta at least (not going to guarantee 1.0+, there are some performance implications) we're actually enforcing this. If a response we're to somehow not have a required field set, an error will occur ...


2

This was fixed in the latest deploy.


2

There is no difference and... The inbox has always been "The global inbox". Certainly for as long as the API has existed. So any inbox route will be Stack Exchange wide, even if it accepts a site parameter. If you look at the doc for the /users/{id}/inbox/unread route, it says: This method is effectively an alias for /inbox/unread. It is provided for ...


2

This is a very minor bug in the documentation page. The online doc page adds a convenient hyperlink to the post (The link part is not in the API's JSON response). That's a good thing. Most of the time this is rock solid, but notifications span all Stack exchange sites and the API doc pages normally only expect one site at a time. When the page is making ...


2

This is just the reputation that the user has earned for the given period (day/week/month/quarter/year). For example, for you, for Stack Overflow, the API currently returns: "reputation_change_day": 0, "reputation_change_week": 0, "reputation_change_month": 32, "reputation_change_quarter": 63, "reputation_change_year": 111, This should jibe with what ...



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