Request: Expose more Properties in the "Update a thread" (PATCH) endpoint

[baribeau]

As documented at https://developers.hubspot.com/docs/api/conversations/conversations, the "Update a thread" (in the conversations.write scope) endpoint is serviced by making a PATCH request to /conversations/v3/conversations/threads/{threadId}.

In addition to the required threadID property, it accepts as inputs only "status" (which must be OPEN or CLOSED) and "archived". 

But in its response, it includes a much more complex object. The sample provided in the documentation is:

{
  "id": "2627121",
  "createdAt": "2018-08-21T12:06:22.029Z",
  "status": "CLOSED",
  "latestMessageTimestamp": "2018-08-21T12:06:22.889Z",
  "latestMessageSentTimestamp": "2018-08-21T12:06:22.889Z",
  "latestMessageReceivedTimestamp": "2018-08-21T12:06:22.889Z",
  "assignedTo": "A-123",
  "spam": false,
  "inboxId": "123",
  "associatedContactId": "7206",
  "archived": false
}

It would be useful to be able to include several of this properties in the request. I'm especially interested in "associatedContactId" (use the API to change which contact a conversation is associated with), but I could imagine potential use cases for being able to update "inboxId" (to use the API to move conversations to different inboxes) and "assignedTo" (to use the API to create more complex assignment rules) as well.

[GSchlegel]

I desparately need to be able to move threads into different inboxes. 

Use case: we have about 15 legacy email addresses that we did use in the past and that still light receive e-mail. And we want to consolidate all of that into a single HubSpot with a single address.

However the service agents now have the choice to send from all these legacy addresses and even that they have a choice at all causes confusion.

My idea is to connect all legacy addresses with a legacy service inbox and to automatically move every conversation that pops up in the legacy inbox into the new service inbox. Service agents will not have access to the legacy inbox, so they cannot choose the legacy addresses anymore.

[EricHirsh]

We've heard in a few different places requests for the ability to change a thread's associated contact, assigned owner, and what Inbox it is in. No firm timelines to report but happy to consider these!

@GSchlegel for your case (don't want reps confused by a long dropdown of sending addresses, but do still want to receive email from old addresses), have you thought about implementing some forwarding rules on those old email addresses instead of automating inside HubSpot/API?

[GSchlegel]

Sure, just forwarding the legacy addresses into our main service inbox has been our first approach.

Unfortunately HubSpot does not detect the old addresses as “native HubSpot Inbox addresses" in that case, so it adds these addresses as a contact and on the created tickets thereby cross-links all the tickets opened by our customer via legacy addresses with each other. Took us some time to clean that up after the go-live of the service desk. And the immediate action has been to route every legacy address into a dedicated single mailbox and import thase into HubSpot.