Mark specific posts as "read" through the API?

dev
1

Hello,
I’m pulling posts through the discourse API. I’m using python for that. The request calls the following code (which makes a GET request essentially) and returns the .json similar to this post

    def topic_by_id(self, topic_id, **kwargs):
        return self._get("/t/{0}.json".format(topic_id), **kwargs)

The posts returned have a 'read' flag. The posts I send are read=True, but for the posts I receive they are all marked as read=False, unless I actively log in to Discourse and read them.

Is there a way to mark a specific post as read through the API given a post_id? I’ve been looking into pydiscourse and they offer a method to add reading-time which supposedly also makes a post “read”, but no matter how much read-time I “add” the .json endpoint returns as false. I don’t care about reading “gaps” as long as I can mark specific post ids

    def topic_timings(self, topic_id, time, timings={}, **kwargs):
        """
        Set time spent reading a post
        A side effect of this is to mark the post as read

        Args:
            topic_id: { post_number: ms }
            time: overall time for the topic (in what unit????)
            timings:
        """
        kwargs["topic_id"] = topic_id
        kwargs["topic_time"] = time
        for post_num, timing in timings.items():
            kwargs["timings[{0}]".format(post_num)] = timing
        return self._post("/topics/timings", **kwargs)

Similar functionality has already been achieved for notifications using the notifications/mark-read endpoint

    def mark_read(self, notification_id):
        return self._put('/notifications/mark-read.json', id=notification_id)

Also, another valid workaround is if it’s possible to mark a whole topic (all posts within) as read

Any help is welcome!

EDIT: it is required that this also functions for private-messages

2

Well, I’ve reverse-engineered it with the browser.
the topic_timings() must be called using post index in the timings={} argument instead of the post ID.

I guess that’s quite acceptable workaround, though I’d like to have a post-id-based method because it’s not very easy to infer index from ids (will need to fetch the actual topic first)

3

I don’t know if this will help, but I believe there is a /p/<POST_ID> route.