Webhooks: how best to differentiate a PM from a public post

Hi All,

I’ve been scrutinizing the various JSON post results from our webhooks. We record and react to public posts that contribute to our common knowledge-base differently than PMs or discobot conversations. For example, it’s relatively easy to filter out posts from discobot using its userid; likewise with system posts and topics. However, I haven’t been able to identify a reliable way to filter posts back to discobot, or PMs between two users. At first I thought only PMs had a “reply_to_user” field, but it appears that some (but not all) posts have it also. Here is an example of what we are trying to filter out:

"post": {
    "id": 1296,
    "name": "Test User",
    "username": "testuser",
    "avatar_template": "/letter_avatar_proxy/v2/letter/c/stringhere/{size}.png",
    "created_at": "2017-12-14T21:11:30.992Z",
    "cooked": "\u003cp\u003e[quote=\"cutlery, post:11, topic:626\"]\u003cbr\u003eIf this is coffee, please bring me some tea; but if this is tea, please bring me some coffee\u003c/p\u003e",
    "post_number": 13,
    "post_type": 1,
    "updated_at": "2017-12-14T21:11:30.992Z",
    "reply_count": 0,
    "reply_to_post_number": 11,
    "quote_count": 1,
    "avg_time": null,
    "incoming_link_count": 0,
    "reads": 1,
    "score": 0,
    "yours": false,
    "topic_id": 626,
    "topic_slug": "robot-greetings",
    "topic_title": ":robot: Greetings!",
    "display_username": "Test User",
    "primary_group_name": null,
    "primary_group_flair_url": null,
    "primary_group_flair_bg_color": null,
    "primary_group_flair_color": null,
    "version": 1,
    "user_title": null,
    "reply_to_user": {
        "username": "testuser",
        "avatar_template": "/letter_avatar_proxy/v2/letter/c/stringhere/{size}.png"
    "actions_summary": [{
        "id": 2,
        "can_act": true
    }, {
        "id": 3,
        "can_act": true
    }, {
        "id": 4,
        "can_act": true
    }, {
        "id": 5,
        "hidden": true,
        "can_act": true
    }, {
        "id": 6,
        "can_act": true
    }, {
        "id": 7,
        "can_act": true
    }, {
        "id": 8,
        "can_act": true
    "moderator": false,
    "admin": false,
    "staff": false,
    "user_id": 1234,
    "hidden": false,
    "hidden_reason_id": null,
    "trust_level": 0,
    "deleted_at": null,
    "user_deleted": false,
    "edit_reason": null,
    "can_view_edit_history": true,
    "wiki": false

It’s messy, but if you setup both a Post and a Topic webhook. When a message, or topic is first created, both hooks will be fired. You can use the topic_id that is sent with the Post webhook to get the topic archetype from the topic webhook data. It will be set to ‘private_message’ for messages, ‘regular’ for regular topics.

It would be great to get some topic data sent with the Post webhook - category_id and archetype would both be useful.


Thanks Simon, we’re also struggling with not getting consistent topic_created events. Instead we get post_created with post_number = 1 and no topic_created. We checked both our logs and API/webhooks - nothing. That changed today, which now leaves me at a loss. More here:


Why does it matter? post_created with post number 1 is definitely a new topic. What else could it be?

It didn’t, and we shrugged it off until we saw what we originally expected in the log today: topic_created and no post_created header with post_number = 1. Now we’ve seen both and I’m trying to understand why and what the expected behavior is. It matters because we missed an event that is one of the purposes of the webhook: record and reward users who create a new topic.


I see, @tgxworld can you comment on this please?

Yea those are definitely useful. Another thing that I noticed is that we’re sending the suggested_topics in the webhook payload. It adds quite abit of size to the payload and I don’t think alot of people are using that.


@tgxworld Based on Simon’s reply, is the best way to differentiate a PM to make a request back to the API at “topics/get a single topic by id” and pass the ID for every post? Then if the archetype comes back private_message we’ll filter it out, if it comes back “regular” we’ll use it. We seem to get either a post created with post_number = 1 or a topic_created with no post_created. We’ll check for both and that should cover our use cases.

Is there any documentation on the JSON fields, possible values, and meaning for topics, posts, and users? For example, are there other possible values for archetype? What does actions_summary signify with id=n? Alternatively, if you could point us to somewhere in the code base that builds the JSON objects passed in the webhooks that would be something. We poked around but couldn’t find the data itself, just the events and objects passed.

Any chance these might be topics that were moved or had ownership reassigned? Staged users?

I don’t think so. We have a very active group of veterinarians posting, but it’s very vanilla stuff. Topics and replies. To my knowledge no one has reassigned or moved a topic. We don’t stage users.

1 Like

We’re running into a similar problem with the topic archetype not being in the post webhook. We’re using the webhook to create tickets in our support ticketing system when someone publicly posts or sends a private message to us. The problem is we handle public posts and private messages differently so we need to know the type in the webhook handler.

I appreciate that we can use the API to call back and get the topic details but it seems like a lot of work and overhead when this info could be in the post event payload.

Is there any chance you might be willing to add it? Would you be amenable to a pull request if we added it?

1 Like

Pull requests are always welcome :wink:


PR submitted. Added the topic archetype and the category slug.