Statuses

Statuses track a thread’s progress. You choose their names, colors, and order; Support uses one of four categories to filter the queue and automate replies. Renaming a status does not change its category or behavior.

Names are yours, categories are ours

Each status has four fields:

Categories drive automation and reporting. For example, you can rename a pending status to “Waiting on customer”, create “Triage” and “In progress” in open, or add “Won’t fix” in closed without changing the category rules.

The seeded default set

The first support_status_list call on a new product creates and returns these defaults:

Repeated or concurrent first reads produce one default set. The list sorts by order, then by name when orders match. Archived statuses are hidden unless you set includeArchived.

support_status_get reads a single status by id, including archived statuses, in the same shape as a list entry.

Adding and editing

support_status_create requires all four fields. A duplicate name returns a conflict.

support_status_update changes name, color, and order. It can change category only while no thread references the status. Otherwise it returns a conflict: changing the category would also change how existing threads are classified for reporting. Create a status in the required category and move the threads instead.

Setting order does not renumber other statuses. Duplicate orders are allowed and sort by name.

Retiring one

Use support_status_archive to archive a status and move its threads to another live status. Replace the abbreviated ids with your source and destination status ids:

{ "id": "d6284a3e…", "targetStatusId": "4463741a…" }

The target must be a different, non-archived status in the same product. Support moves every affected thread and archives the source in one transaction. No thread remains on the archived status.

Archived statuses stay readable for historical references, but cannot receive threads. Statuses cannot be deleted.

The one automatic transition

A public inbound message on a thread in the pending category moves it to the product’s default open status: the non-archived open status with the lowest order. The message and status change are saved in the same transaction.

All three conditions must hold:

• direction is inbound; an outbound reply does not trigger the move.
• visibility is public; an internal note does not trigger it.
• The current status category is pending. Threads in open, resolved, or closed stay on their current status, including custom open statuses.

The rule applies to every pending-category status, including renamed and custom ones. It can run whenever these conditions hold.

For other moves, call support_thread_status_set. Replace the ids with your thread and destination status:

{ "id": "b50f26b4…", "statusId": "87e60f77…" }

Any live status may follow any other, including a return to a previous status. Pass the status id; the category is read from that status. An archived destination is rejected, and a status from another product returns not found.

Where to go next

• Threads and messages: create and filter threads.
• Notifications: check which changes notify your team.
• Tools, SDK and errors: look up status operations.