I updated several aspects of the app in response to user feedback:
Error handling is somewhat better (it will now tell you if your token is invalid, instead of a generic "error" alert)
Queued API calls are aborted now, which should speed up site changing, among other things.
There's now an option to deauthorize the app, should you decide to revoke its ...
EDIT: Implemented using Web Sockets (because the caching characteristics of the API does not allow real-time notifications). I created a Chrome extension and Firefox add-on, and created a Stack Apps listing at Real-time desktop notifications for Stack Exchange inbox.
In Google Chrome, the popup is closed when performing an action outside it (clicking, ...
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 ...
Some comments on the new features:
I really dislike an authentication flow which mandates a call out to a browser. It makes command line applications basically impossible. It makes consistent UIs for specific platforms very hard (e.g. iPhone), as you basically have to dump the user into a web browser with an entirely different UI. It also ...
Yes, you can change very nearly everything (and actually everything that's user entered) about an application after it's been registered.
You should use the domain you intend to host the client-side app under as your OAuth Domain. While not strictly necessary, it's the sanest option.
I would like to see fixed paging. And yes, that means I think the current system is broken.
What do I mean by broken? When you want to get 500 newest questions and the page size is 100, it's impossible to do so without the possibility of duplicates (which are easy to ignore) or (much worse) missing questions.
This happens because you can access page 1, ...
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 ...
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 ...
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 ...
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.
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 ...
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.
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.
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 ...
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
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 ...
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.
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 ...
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 ...
I'm going to lay some ground work about authentication and access tokens before answering, because I think you have some misconceptions.
When a user authenticates an application they have given permission for it to access their data in certain ways (via scope). The actual mechanism* for accessing this data is an access token, but the authorization to get ...
Each application/user pair (as signified by an access_token) has a per-day quota of 10k requests (by default). Any number of these can be in flight at once, and they're reported as part of quota_remaining and quota_max.
On top of that, is a per-user quota of 50,000. This quota isn't reported anywhere (for privacy reasons, we'd rather not leak a user's ...