Tickiti

Reply to ticket API

This article and the rest of the API documentation in this section are written for a technical audience — integrators and developers connecting external systems to Tickiti. Familiarity with HTTP, REST, JSON and bearer-token authentication is assumed.

The reply endpoint posts a response onto an existing ticket. Use it when an external system has new information to add to a conversation Tickiti is already tracking — for example an order system posting a shipping update, or a CRM adding a note when a customer record changes.

Endpoint

POST /api/v1/tickets/respond

Headers

  1. Authorization: Bearer YOUR_TOKEN — required. Token must have the tickets:write ability.
  2. Idempotency-Key: <uuid> — required. See Idempotency.
  3. Content-Type: application/json — required.

Body

Required fields:

  1. ticket_number — the 6-digit number of the ticket to respond to. The ticket must exist.
  2. from_email — the email address the response is attributed to. If this address is not already a participant on the ticket it is added as one.
  3. content — the response body (string, HTML allowed).

Optional fields:

  1. is_internal — boolean, default false. When true the response is a staff-only internal note and is not shown to the customer or included in customer notifications.

Example

curl -X POST https://support.sole-provider.example/api/v1/tickets/respond \
  -H "Authorization: Bearer $TOKEN" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "ticket_number": "220009",
    "from_email": "fulfilment@sole-provider.example",
    "content": "<p>Your replacement Vapor Pro 3 has shipped. Tracking: TRACK-XYZ.</p>"
  }'

Successful response

{
  "ok": true,
  "data": {
    "ticket_id": 1,
    "response_id": 42,
    "reopened": true
  }
}

reopened is true when the response moved a closed or on-hold ticket back to Open. Posting a response always reactivates a ticket that was not already open and clears any on-hold timer, so the conversation surfaces to staff again.

Error responses

  1. 422 validation_failed — missing field, unknown ticket number, malformed email.
  2. 409 idempotency_key_conflict — the idempotency key was already used with a different payload. See Idempotency.
  3. 401 unauthenticated — bad or missing token.
  4. 403 forbidden — token does not have the tickets:write ability, or the user it acts as lacks access to the ticket’s queue.

What happens server-side

  1. Tickiti locates the ticket by ticket_number.
  2. It writes the response, public or internal per is_internal, attributed to from_email.
  3. It adds from_email as a participant if it was not one already.
  4. It reopens the ticket if it was closed or on hold, and clears any on-hold timer.
  5. It refreshes the affected ticket-list views and notifications.