Webhook events

Agent runs are asynchronous — they may take seconds, minutes, or hours depending on the work the agent performs. Subscribe to agent webhook events to receive real-time updates about run lifecycle changes instead of polling the Run endpoint.

Configure webhooks to receive notifications when agent runs are created, completed, or interrupted. These events use the same delivery pipeline as Middesk’s other webhook events: identical retry behavior, authentication options, and 2xx success contract. See Implement webhooks for setup details and Secure webhooks for signature verification.

When a run interrupts, your endpoint receives the agent’s open question and proposed artifacts so you can take action before the run resumes.

Choosing events by review model

The events you need depend on where your team reviews agent findings:

Each event has one job:

• run.interrupted asks for your input. Subscribe when your own system presents findings to reviewers and responds through Take action. If reviews happen in the Middesk Dashboard, or an interrupt policy resolves them automatically, you can skip it.
• business.updated tells you the Business record may have changed after a review is resolved. Note: runs that error or propose nothing never send business.updated.
• run.completed tells you a run is finished, whatever the outcome. It fires once for every run, including runs that error or never propose changes. Subscribe when your workflow waits on runs to finish.

Agent outcomes and business.updated

For agent work, business.updated signals that a review was resolved. It fires after findings are approved, rejected, or skipped, whether a reviewer resolved the review or an interrupt policy did.

Use the event as a signal to refresh your stored Business.

By default, the business.updated payload doesn’t identify agent runs. To see which runs contributed to an update, add the runs field with a custom event schema, then pass the run id to Retrieve an agent run for full details.

Run events

Sample payloads

Run events also include the X-Correlation-ID header, using the same convention as business.updated: the business’s external_id when set, otherwise the Middesk business id. When a run is started with an inline business payload for a business that does not exist yet, run.created has "business_id": null; later run.interrupted and run.completed events include the business id after the run’s context is backfilled.

1
{
2
  "object": "event",
3
  "id": "a1b2c3d4-5678-90ab-cdef-1234567890ab",
4
  "type": "run.created",
5
  "data": {
6
    "object": {
7
      "object": "run",
8
      "id": "c1d2e3f4-5678-90ab-cdef-1234567890ab",
9
      "business_id": null,
10
      "created_at": "2026-01-15T12:00:00.000Z",
11
      "updated_at": "2026-01-15T12:00:00.000Z",
12
      "status": "running",
13
      "started_at": "2026-01-15T12:00:01.000Z",
14
      "ended_at": null,
15
      "steps": [],
16
      "interrupts": []
17
    }
18
  },
19
  "created_at": "2026-01-15T12:00:01.000Z"
20
}