Support tickets
The enterprise support portal API - open a ticket, exchange a message thread with the Zumik team, and track status. First-response SLA is derived from the project's plan tier.
The support portal is a first-party ticketing surface. A project opens a ticket, exchanges a message thread with the Zumik team, and tracks status. The SLA - first-response target and whether the ticket jumps the queue - is derived from the project's billing plan, so a Pilot or Enterprise contract gets a faster, prioritized response. Support is available to every customer; the tier is what scales with the plan.
The console Support tab is the same API with a UI.
SLA by plan
| Plan | Tier | First response | Priority queue |
|---|---|---|---|
| Free | community | Best effort, community support | — |
| Base | standard | 1 business day | — |
| Pilot | priority | 4 business hours | Yes |
| Enterprise | enterprise | 4 hours, 24/7 for urgent issues | Yes |
The SLA is snapshotted onto the ticket at creation, so a later plan change doesn't retroactively weaken an open ticket's commitment.
Open a ticket
curl https://api.zumik.ai/v2/support/tickets \
-H "Authorization: Bearer $ZUMIK_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"subject": "Streaming cuts off mid-response",
"body": "When I set stream:true the connection drops after ~30s.",
"priority": "high",
"contact_email": "[email protected]"
}'priority is one of low, normal (default), high, urgent. contact_email is optional - the console prefills it from your session. The response is the full ticket, including its sla and the opening message:
{
"id": "spt_...",
"object": "support_ticket",
"subject": "Streaming cuts off mid-response",
"priority": "high",
"status": "open",
"plan_tier": "enterprise",
"sla": { "tier": "enterprise", "first_response_target": "4 hours, 24/7 for urgent issues", "priority_queue": true },
"contact_email": "[email protected]",
"messages": [
{ "id": "spm_...", "author": "customer", "body": "When I set stream:true ...", "created_at": "..." }
]
}Read and reply
| Action | Request |
|---|---|
| List tickets | GET /v2/support/tickets |
| Get one | GET /v2/support/tickets/{id} |
| Reply | POST /v2/support/tickets/{id}/messages |
| Set status | PATCH /v2/support/tickets/{id} |
A reply appends to the thread:
curl https://api.zumik.ai/v2/support/tickets/spt_.../messages \
-H "Authorization: Bearer $ZUMIK_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "body": "Here is the full request body and a HAR file." }'Replying to a resolved ticket reopens it. A closed ticket is final - open a new ticket instead.
PATCH sets the status to one of open, pending, resolved, or closed:
curl -X PATCH https://api.zumik.ai/v2/support/tickets/spt_... \
-H "Authorization: Bearer $ZUMIK_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "status": "resolved" }'Notifications and privacy
New ticket activity best-effort-notifies the Zumik team (a Resend email when configured, plus the shared ops webhook); a notification failure never fails your request. Tickets are scoped strictly to the owning project - you can never read another tenant's ticket. They carry contact emails and message bodies (personal data), so they are included in a data export and erased by a deletion request.
BYOC clusters
Register, list, retrieve, heartbeat, and deregister bring-your-own-cloud clusters. The control plane records your data planes; it never holds GPUs.
SDKs
The four first-party Zumik SDKs - Python, TypeScript, Go, and Rust - with install, ZUMIK_API_KEY auth, the /v1 OpenAI-compatible vs native /v2 split, and a capability matrix.