Redacted / deleted conversation parts need to be identifiable

Hello lovely people :wave:

In Intercom, a Teammate can redact / delete a Conversation Part like this:

And so, when inspecting the Conversation Part body either from the API or the Webhooks, it will look like this:

<p><i>This message was deleted</i></p>

There is currently no way to know if this Conversation Part is redacted / deleted or not; other than doing a direct string comparison to the message above, which isn’t very reliable.

I suggest we add an attribute to identify that this Conversation Part is redacted / deleted by either:

  1. Adding a redacted_at / deleted_at attribute
  2. Adding a state attribute: "state": "original" or "state": "redacted" (maybe in the future even: "state": "edited" :wink:

It could look like this:

    "type": "conversation_part",
    "id": "300000000",
    "part_type": "comment",
    "body": "<p><i>This message was deleted</i></p>",
    "created_at": 1557136176,
    "updated_at": 1557136176,
    "notified_at": 1557136176,
    "redacted_at": 1557136222,
    "assigned_to": null,
    "author": {
        "type": "admin",
        "id": "2000000",
        "name": "John Smith"
    "attachments": [],
    "external_id": null

With API versioning available, this can be a good value addition :rainbow:


Hey @khalilovcmd , good to see you here :smiley:

Thanks for the suggestion, looks like a low hanging fruit that we can introduce quickly. Currently we are working towards a launch for June 5 so unlikely to have capacity before then, but we can look into this afterwards!

1 Like

Thank you @hellojeanpierre! No worries and goodluck in the upcoming launch. :blue_heart:

It’s nice being able to expose the little things here, the community gets to be aware of it and also acts like a feature request ledger for you guys :wink:

1 Like

:100: Also makes our life easier knowing what needs to be done!

1 Like

@khalilovcmd we shipped a new webhook topic in 1.2 version for conversation part redacted, could this work?

1 Like

Thanks @hellojeanpierre!

I think this is super useful in general. :+1:

Though Webhook’s payload usually is not be considered as the source of truth, and developers tend to fetch “a conversation with its conversation parts” from the API upon receiving the Webhook event to do all sorts of things, and this acts as the source of truth.

And so, if the source of truth is missing the “redaction” information, it will be slightly impractical to correlate the single Webhook’s payload and the conversation payload returned from the API.