It's pretty simple, you just append your key to the URL as a parameter.
For example, looking for users 1 and 5:
So, it looks like your HTTP.call would become:
Refer to the Stack Exchange API, Authentication docs. It looks like you are trying to authenticate using either a server you do not control, or a local server that is not on the public internet.
Do not specify a redirect_uri to any server that you do not control.
When you use something like redirect_uri=https://www.yahoo.com/, then a third ...
I don't see any particular reason not to add it, but there are some workarounds you can use in the meantime:
Build a cache of all site information with the site URL as the key, and then look up the api_site_parameter value (and associated information) that way.
Use the fact that the domain name can be passed as a valid value for the site parameter, in ...
No. Currently the users type does not return any private_info and neither does the user_timeline type return any voting information.
No other API method allows for detecting a user's vote history except one question at a time. You would have to fetch every single question and test the downvoted and the upvoted properties.
If you limited your search ...
You need to pass in a sufficiently large pagesize value, per the documentation:
The pagesize parameter for this method is unbounded, in acknowledgement that for many applications repeatedly fetching from /sites would complicate start-up tasks needlessly.
Otherwise you'll only get 30 results, the default value for pagesize. Alternatively, you can page the ...
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
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.
This is what custom filters are for.
For example, if you append &filter=!BGRhem4Z)WIti9lP55R*tgr(Jq_fHC to your query, above, you will get results without upvote_count, downvote_count, or owner information. (The first two aren't included by default anyway.)
An easy way to create a filter is to use the filter-edit tool, on the appropriate doc page for ...
Most routes that take an ID, including the /users route, will accept multiple values separated by semicolons. For example, a query like
will give you results for both user 1 and user 22656. You can combine up to 100 ids in this fashion.
link is the best way to distinguish between items. No two items should have the same link, and inbox items aren't updated after they are created; they're snapshots of activity more than references to it.
See the "Safety" heading in the "Custom Filters" doc. The difference between a "safe" (default) filter and an "unsafe" filter, is that the unsafe data might return data that could result in a script injection if the data was directly inserted in an HTML document. (EG: '<script src="PwnYaSucka.com">...')
Some fields are apparently inherently devoid ...
By "bio" you mean the about me field, right? ...
Any path that returns a user object will return the about_me property, but this is not returned by default. You have to use a filter that has about_me enabled.
For example, here is a query to get your "About me" on stackapps:
An easy ...
The API allows you to set a pagesize of 0 to 100 (with the exception of the /sites route, which allows larger values), and defaults to a maximum of 30 items in the response.
To get all of the items applicable to the API query, you need to check the has_more field to determine if you need to request subsequent pages via the page parameter. This is covered in ...
You can get data close-enough to "real time" for most practical purposes. See the StackHose app, for example.
Read the page about the API's Throttles and Quotas. From that page we can deduce:
The maximum, burst, request rate is 30 requests per second, and this risks getting your app shut down.
Your app will never be allowed more than 10,000 requests per ...
status-completedI asked this as a question, but apparently the convention is to report bugs/feature requests in the announcement thread.
It appears, that the MathJax extension mhchem is currently not enabled in the StackPrinter app. This is rather inconvenient for most of the chemistry.se questions and answers. It would therefore be nice if this feature ...
Could you add progress towards the Enlightened and Guru badges for answers too?
These would list accepted answers that have scores close to 10 and 40 respectively (with the Enlightened candidates limited to first answers only), as well as list not-yet-accepted answers where the score (and "first answer") criteria have been met and would qualify for just ...
To find user_id(s) for a username, use the inname parameter of the /users query.
You will have to repeat this query call for every Stack Exchange site that you are interested in. For example:
There is an /events route that:
"Returns a stream of events that have occurred on the site."
Greg Hewgill has created a firehose JSON streaming event service which closely mimics the Twitter Streaming API.
He has also created a page to demo the service here: StackHose: live real-time event stream in your browser
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.
Since the .getTime() value is already in UTC, you can just divide by 1000, and round.
var apiDate = Math.round (new Date().getTime() / 1000);
works just fine.
apiDate is in "unix epoch time" and the API takes these values even if the API parameter is called a "Date".
But, if you want to truncate to the date only, just use:
var dateTime = new ...
The API does not provide any method to determine a user's email address and it is unlikely to do so in the future.
This would be a risk to both the user's privacy and his/her trust in Stack Exchange. And, a pressing need for this information has yet to be demonstrated, regarding the API.
Note that Stack Exchange refuses to even provide the user's email hash ...
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.
OK, well, I've pretty much confirmed that A LOT has changed with version 2.0... the new release does not appear to be backwards compatible with version 1.1 at all. Kind of annoying if you ask me. For now I'm going to modify StackWrap4J myself and just copy and paste the modified source code into my app... if anyone is interested in partnering up to extend ...