Skip to main content

Reply to Intake Ticket

POST 
/api/support/intake/tickets/:ticket/messages

Adds a public reply to the thread as the customer. The author is the address in X-Support-Requester-Email; a colleague who replies on a ticket they are not yet on is added as a watcher. CCs are the ticket's own and cannot be overridden here.

Environment intake token

Called by another SKU environment (beta, demo, dev) on behalf of its users: authenticate with that environment's intake token and the origin headers described below — not with a Personal Access Token or a session.

By default a customer reply on a ticket that is in progress, waiting on the customer, resolved or closed moves it back to open and notifies the assignee — the desk's built-in reopen-on-customer-reply automation, which a support administrator can change.

Request body — send as multipart/form-data when including files

  • body (required, string, max 65000)
  • attachments[] (optional, array of files, max 10, each up to the desk's attachment size limit)

The response is the new message; mentions is always empty on a public reply.

If the ticket was merged into another, the request is refused with a 422 whose merged_into (id, number) names the live ticket — send the reply there instead.

What this caller can see: the mapped production tenant's organisation-wide tickets, plus every ticket raised from the address in X-Support-Requester-Email — whichever environment raised them. A ticket outside that set is reported as not found, never as forbidden, so a ticket id can never be probed from another environment.

Authentication: the environment token as Authorization: Bearer, plus the X-Support-* identity headers described on the Intake folder. There is no session and no tenant context. An unknown token, or a token presented with another environment, is refused with 403; incomplete identity headers are 422.

Request​

Responses​

Created

Response Headers
    Content-Type