Support Tickets

Raise and follow up on support requests from your own tooling, instead of opening the Support Center in the Studio. Useful when your monitoring, deployment pipeline or internal helpdesk should be able to file a request directly.

Operation	Endpoint	Scope
Raise a ticket	POST /api/v1/support/tickets	support:write
List your tickets	GET /api/v1/support/tickets	support:read
Get one ticket	GET /api/v1/support/tickets/{id}	support:read
Reply	POST /api/v1/support/tickets/{id}/reply	support:write

Raising a ticket

curl -X POST "https://<your-workspace>-api.perfox.ai/api/v1/support/tickets" \
  -H "Authorization: Bearer sk_…" \
  -H "Content-Type: application/json" \
  -d '{
    "subject": "Voice agent drops tool calls on long calls",
    "description": "Reproduces after ~6 minutes. Conversation ids attached in the thread.",
    "category": "platform",
    "severity": "high"
  }'

Field	Values
subject	3–200 characters
description	The problem statement, up to 8,000 characters; becomes the first message in the thread
category	forward_deployment for help with your implementation, platform for a suspected product defect
severity	low, medium (default), high, urgent
requester_email	Optional — see below

The response is 201 with the ticket:

Field	Meaning
id	Ticket id, for the other calls
ticket_number	The number shown as SUP-<n> in the Support Center
subject, description, category, severity	As raised
status	open, in_progress, awaiting_customer, resolved or closed
created_via	studio, api or chatbot
created_by	name and email of the requester
assigned	Whether someone on the support team has picked it up
messages	The thread: each message has author_kind (requester or responder), author_name, body and created_at
created_at, updated_at, last_activity_at	Timestamps

Who the ticket is from

An API key identifies a system, not a person, so tickets raised this way are attributed to API integration and marked created_via: "api".

To attribute one to a colleague instead, pass requester_email. It must match someone in your own workspace; anything else is rejected with 400. That check is deliberate — the requester is who the support team replies to, so it is never recorded unverified.

Replying

curl -X POST ".../api/v1/support/tickets/$ID/reply" \
  -H "Authorization: Bearer sk_…" -H "Content-Type: application/json" \
  -d '{"body": "Still reproducing on the latest build — new conversation id inside."}'

body is 1–8,000 characters; requester_email works here the same way as on creation. Replying to a ticket that was resolved, or that was waiting on you, re-opens it — the same as in the Studio. The response is { "id", "reopened", "message" }, so you can tell whether that happened.

Listing returns every ticket your workspace has raised, most recent activity first, however it was created — Studio, API, or the in-product support assistant. List rows are a summary (with a message_count instead of the thread); get one ticket for its full thread. An id that is not one of your tickets returns 404 not_found.

Attachments

Not yet supported on this endpoint. Include a link in the description or a reply.