3

This question already has an answer here:

Accessing inbox items using the following url:

/me/inbox

Unread inbox items remain unread (is_unread = true) even after that specific item has been read using the API (v2.1).

The items are marked read only after viewing the inbox item in the website.

The same problem exists with:

/me/notifications/unread

The notifications are not cleared until the user visits the website to clear them.

marked as duplicate by Brock Adams Sep 11 '18 at 20:02

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • Still not resolved, but no sense having 2 feature requests for the same thing. – Brock Adams Sep 11 '18 at 20:03
3

Update: Op followed the advice, below, and changed the question from a bug to a feature-request.


This is not really a bug. Right at the top of the API documentation, it states that the API is read-only, in bold letters:

Stack Exchange API v2.0

This is the documentation for the v2.0 read-only (with optional authentication) Stack Exchange API. If you have additional questions, or believe you have encountered a bug, don't hesitate to post a question on Stack Apps.


And neither the /me/inbox, nor the /notifications/unread docs claim to alter the state of the inbox items.

And, yes, that note seems to be misleading since the API does allow modifying comments. But, the docs do not claim any write ability for notification state.

For now, if you wish to avoid rereading "new" inbox items, you must track them in your app.


This might be better as a feature-request, rather than a "bug", since no claimed feature is not working.


If you absolutely want a bot to change the read state, you'll have to use standard page-scraping and/or userscripting techniques to automate the appropriate clicks -- until such time as this inbox-reading feature is added.

Not the answer you're looking for? Browse other questions tagged .