Skip to main content

Create Support Ticket

POST 
/api/support/tickets

Opens a new support ticket for the active tenant. The requester is the authenticated user; the ticket is created open, SLA due dates are set from the SLA policy for the chosen priority, and the request body becomes the ticket's first public message. A ticket opened with a personal access token is recorded with source api; one opened from an app session is app.

Required scope: support:write

Grant this scope to your token under Settings → Developer → Personal Access Tokens.

Request body:

  • subject (required, string, max 255)
  • body (required, string, max 65000) — becomes the opening message
  • type (optional, string) — one of: bug, question, feature_request, billing
  • priority (optional, string, default medium) — one of: low, medium, high, urgent
  • visibility (optional, string, default tenant) — tenant (everyone at your company sees it) or requester (only you, plus participants and agents)
  • context (optional, object) — where the ticket was raised from. It follows a fixed schema and unknown keys are dropped:
    • context.route (string, max 255), context.url (string, max 2048) — the page
    • context.record_type (string, max 100), context.record_id (string, 1-64 characters: letters, digits, _, -) — the record on that page. A recognised record_type (for example sales_order, purchase_order, product, customer, inbound_shipment) adds a record link to the ticket automatically
    • context.browser (string, max 512), context.viewport ("WIDTHxHEIGHT" or {width, height}), context.build (string, max 120)
    • context.tenant_id (string, max 100), context.pod (string, max 100), context.user ({id, email, name}) — filled in by the server from the request when omitted, so every ticket records who raised it from where
    • context.recent_errors[] (array, max 10) — each {at (max 40), method (max 10), url (max 2048), status (100-599), message (max 1000)}
    • context.sentry_event_ids[] (array, max 20, each max 64 characters)
    • context.breadcrumbs[] (array, max 200) — the trail of what the user did just before opening the ticket, oldest first. Each entry is {t (string, max 40 — when it happened), kind (required, one of route, click, xhr, error), label (string, max 200), detail (string, max 200, optional)}. Unknown keys are dropped, an unrecognised kind is rejected, and when more than 200 entries survive cleaning the newest 200 are kept
    • context.screenshot_attachment_id (integer, nullable), context.screenshot (boolean)
  • cc[] (optional, array, max 20 emails) — additional people to notify on replies
  • attachments[] (optional, array of files, max 10, each up to the account's attachment size limit) — send as multipart/form-data when including files

The response is the new ticket. first_response_sla_status and resolution_sla_status report the ticket's two SLA clocks: one of on_track, breaching_soon (past the policy's warning point, by default 75% of the way from creation to the due date), breached, paused (the ticket is waiting on the customer, so neither clock warns), met (responded / resolved before the due date). merged_into is {id, number} once the ticket has been merged into another, otherwise null.

Authentication: Bearer token with the support:write scope, or an authenticated session. Requires the X-Tenant-Id header (or a tenant subdomain).

Request​

Responses​

Created

Response Headers
    Content-Type