Recipe: Route a ticket

This recipe lists the calls, in order, that take you from nothing to an agent that routes a support ticket to an L1, L2 or L3 queue. It is the API side of the ticket triage cookbook, which explains the workflow graph itself (collect the ticket, classify it, normalise the values, branch, ask an owner to approve an escalation, reply). Use that page’s graph, or start with the three-node graph in the updateWorkflow example.

Steps 1 to 7 are one-off setup with a dashboard JWT; step 8 is what your server does for every ticket, with the API key. Every call also sends x-huat-platform: customer (see the Authentication cheat sheet).

Step	Call	Credential	What you keep
1	createAgent	JWT	the agent id
2	createWorkflow	JWT	the workflow id
3	updateWorkflow with nodes and edges	JWT	nothing; this saves the draft
4	workflowDiagnostics (optional)	JWT	findings to fix before publishing
5	publishWorkflow	JWT	nothing; sessions now run this version
6	updateAgent with input.workflowId	JWT	nothing; the agent now runs the workflow
7	createNamedApiKey	JWT	the API key, in your server’s secret store
8	The Hello ticket program, or runWorkflowTask	API key	the reply, or the task outcome

Which entry point to use

• A conversation (the user describes the problem, the agent asks follow-up questions): start a session with sdkStart and send messages, as in the Hello ticket quickstart. The cookbook graph is written for this: it waits for the user’s answers with await_reply.
• A ticket that already exists in your system (no chat, the facts are known): call runWorkflowTask with the facts in variables (for example subject, reporterRole), then poll workflowTaskOutcome with the returned sessionId. Read the values in the graph as {{subject}} instead of asking for them.

Making it act on your systems

• To create or update the ticket in your ticketing backend, register the call as a custom action and test it before a workflow action node uses it, or expose your tools through an MCP connector.
• To let the classifier quote your own articles, create a knowledge base and set knowledgeBaseId on the llm node.
• Escalations that need a person go through an approval node; a workspace owner decides them with the approvals operations.