reopen_support_conversation

Put a resolved support thread back in the creator's open queue so it shows in the triage list again.

Purpose

Reopen a thread by hand. It goes back to open, resolved_at is cleared, and it competes for the creator's attention again. The reverse of resolve_support_conversation.

A member writing again reopens their own thread without this, so call it only when the creator wants to follow up first — a refund that turned out to be wrong, an answer that needs a correction. It is also the only way back for a thread whose member is blocked: their messages are dropped, so they can never reopen it themselves.

The row is left alone when the thread is already open, but support.conversation.reopened fires on every call — the same event the member's own message would raise, so a consumer cannot tell a manual reopen from an inbound one. Deduplicate on the event id if you post notifications downstream.

Required ability

support-conversation:update

Input schema

{
  "type": "object",
  "required": ["conversation_id"],
  "properties": {
    "conversation_id": {
      "type": "string",
      "description": "UUID of the support conversation to reopen."
    }
  }
}

Output shape

{
  "data": {
    "id": "9e042b6f-5d81-4c37-a920-7b3e18cf6d45",
    "project_id": "7f3d1c92-8b45-4e6a-9d21-5c8e0a4b6f13",
    "channel": "telegram",
    "status": "open",
    "assigned_to_user_id": null,
    "unread_count": 0,
    "blocked": false,
    "first_response_at": "2026-08-20T10:12:00+00:00",
    "resolved_at": null
  }
}

first_response_at survives the reopen — it is stamped once, on the first human reply ever, and never reset. unread_count is not touched either: reopening does not pretend the member wrote something new.

Example prompts

"Reopen support conversation 9e042b6f-5d81-4c37-a920-7b3e18cf6d45 — I told them the wrong renewal date."

"Put Jane's thread back in the queue so I remember to follow up tomorrow."

"Reopen every thread I resolved in the last hour." (list with status: resolved, then reopen each)

Failure modes

  • VALIDATION_FAILED — the token's owner is on the project's team but their role lacks the support permission on it.
  • RESOURCE_NOT_FOUND — unknown conversation_id, another creator's thread, or a project outside the token's scope:project: allow-list.
  • AUTHENTICATION_REQUIRED — no authenticated user on the request.
  • TOKEN_MISSING_ABILITY — token lacks support-conversation:update.

How is this guide?

On this page

Subscriby is a product designed by you — for you.

No boardroom full of executives deciding what we ships next. Our roadmap always shaped by you with your feedback.

Share feedback or a request