Dispatch

Most support tickets are not questions. They are bug reports wearing a question as a disguise. Dispatch sends one to your repo so a coding agent can fix it.

The loop: a customer reports something broken, you dispatch the ticket, a GitHub issue opens on your repo mentioning your coding agent, the agent opens a PR, you review and merge, and the ticket resolves itself when the fix lands.

Setup

In Integrations, set the repo as owner/name and add a fine-grained GitHub token with issues write access on it. Then add a repo webhook pointing at /api/webhooks/github, which is what closes the ticket when the PR merges.

An agent can do that second part itself. GET /api/v1/dispatchConfig returns the webhook settings for the workspace, so setup finishes without the dashboard.

Dispatching

From the inbox, the button on any ticket. Or:

POST /api/v1/dispatch
{ "id": 123 }

Holding the workspace API key is the approval, which is the point: your coding agent can run the whole loop unattended if you want it to.

The issue carries the ticket's transcript, so whoever picks it up has the customer's actual words rather than your summary of them.

When the fix lands

Merging the PR fires the repo webhook and the conversation resolves with a note saying the dispatched fix landed. The customer who reported it gets told.

That last part is the reason to bother. Bug reports usually vanish into a tracker and the person who reported it never hears anything. Here the report and the fix stay attached to each other.

What not to dispatch

Not everything is a code change. Dispatch is for reproducible defects. Questions answered badly are a training problem, and dispatching them just fills your repo with issues nobody can act on.