Support tickets (MCP)
- How to open and follow up on AutoTalk support tickets from an AI assistant
- How attachments, markdown and priority work
- The ticket lifecycle, and which transitions you can make yourself
Your assistant can raise support tickets with AutoTalk's team on your behalf, follow the thread, and close the loop — without you leaving your editor. This is useful precisely when you are already there: the assistant has the failing request, the error message and the screenshot in hand, so the ticket arrives with the details support would otherwise have to ask for.
create_support_ticket writes to AutoTalk's support queue. To message your end users, use send_message instead — see MCP Servers.
Prerequisites
The same API token and MCP endpoint as every other tool — nothing extra to enable.
The tools
| Tool | What it does |
|---|---|
create_support_ticket | Opens a ticket. subject, body, optional category, priority, attachments, requesterUserId |
reply_to_support_ticket | Adds your reply to a ticket and notifies the support team |
get_support_ticket | Returns one ticket with its full reply thread |
list_support_tickets | Lists your tickets, most recent activity first. Optional status, page, limit (default 20, max 50) |
resolve_support_ticket | Marks a ticket resolved because the problem is fixed |
reopen_support_ticket | Reopens a resolved ticket when the problem comes back |
Every tool is scoped to your own company. A ticket belonging to anyone else simply reads as ticket_not_found.
Opening a ticket
Ask in plain language — the assistant fills in the rest:
Open a high-priority technical ticket about the Telegram channel dropping messages since this morning, and attach the screenshot I just took.
body is markdown, and it renders as markdown in the ticket view and in the notification email. Lists, code, bold and links all survive, so paste the failing payload in a fenced block rather than flattening it into a sentence.
{
"subject": "Telegram channel stopped delivering inbound messages",
"body": "Since ~09:00 UTC today, inbound messages stop at the webhook.\n\n- Channel: `tg-main`\n- Last delivered message: 09:04 UTC\n- Outbound still works\n\nWebhook response:\n\n```\n502 Bad Gateway\n```",
"category": "technical",
"priority": "high"
}
category is one of billing, technical, account, feature_request, other — it defaults to other. An unrecognised value falls back to the default rather than failing the call.
Attachments
create_support_ticket takes up to 6 attachments as storage references:
"attachments": [{ "bucket": "autotalk-prod", "fullPath": "companies/<id>/api/images/mcp_upload/<id>.png" }]
Get those references from upload_file_inline, or begin_file_upload + complete_file_upload — the same flow described in Uploading files. A screenshot of the broken screen usually resolves a ticket faster than paragraphs describing it.
References are checked against your own storage prefix. A path belonging to another tenant is dropped from the ticket rather than attached, so an attachment that silently fails to appear is usually a path from the wrong company.
Attachments are accepted when the ticket is opened. To add one to an existing ticket, upload it and include the reference in a reply body as a link.
Who the ticket comes from
/v1 authenticates a company, not a person, so a ticket opened over MCP is attributed to the company owner by default.
To attribute it to a specific teammate, pass requesterUserId. That user must belong to your company — otherwise the call fails with requester_not_in_company, which is deliberate: it stops a ticket being filed in someone else's name.
Priority and response targets
priority sets the response target support works to:
| Priority | Target |
|---|---|
urgent | 2 hours |
high | 8 hours |
normal | 24 hours (default) |
low | 72 hours |
These are wall-clock targets from the moment the ball is in support's court — when you open a ticket, and again each time you reply. Reserve urgent for support having genuinely stopped; inflating priority does not make anything move faster.
Ticket lifecycle
| Status | Meaning |
|---|---|
open | Filed, not yet picked up |
pending_agent | Waiting on AutoTalk |
pending_customer | Waiting on you |
resolved | Fixed — reversible |
closed | Terminal |
What you can do yourself:
- Reply at any time except on a
closedticket. Replying to aresolvedticket reopens it, so you don't needreopen_support_ticketjust to add "it's back". - Resolve from
open,pending_agentorpending_customer. This is the polite way to close the loop when you fixed it yourself — it stops support chasing a problem that no longer exists. - Reopen from
resolvedonly. closedis terminal. Open a new ticket instead;ticket_closedis what you'll get if you try to reply.
Why not create_document?
support_tickets is read-only to tenants through the generic document tools, and that is intentional. A ticket written directly would have no requester, no response clock and no notification to the support team — it would sit in the database without ever reaching a human. The tools above run the same code path as the support form in the dashboard, so a ticket raised from your editor is indistinguishable from one raised in the app.
You can still read tickets with query_documents; support_tickets is a reserved slug, so it is not available as a custom type name.
Errors
| Error | Meaning |
|---|---|
missing_params | subject or body was empty |
invalid_ticket_id | Not a valid ticket id |
ticket_not_found | No such ticket in your company |
ticket_closed | Cannot reply to a closed ticket — open a new one |
ticket_not_resolvable | Already resolved or closed |
ticket_not_reopenable | Only a resolved ticket can be reopened |
requester_not_in_company | requesterUserId does not belong to your company |
invalid_requester_user_id | requesterUserId is not a valid user id |
no_requester_available | No company owner could be resolved to attribute the ticket to |