[ INTEGRATION SURFACE · BETA ] ━━ API, SDKs, and event payloads may change between releases. Read the versioning policy
▸ ROOT / DEVELOPERS/ EVENT DISPATCH

Event dispatch

Get a Cheetah inspection result into your MES, ERP, or quality system the moment a part is inspected — pushed, not polled.

▸ BETA
▸ APPLIES TO
cheetah service >=0.0.133schema version 2

You run an MES. When a Cheetah cell finishes inspecting a part, you want that result — pass or fail, the measured values, the serial number — in your system the instant it happens, so the traveler advances, the reject gets quarantined, and the SPC chart updates without anyone re-keying a measurement.

Event dispatch is how Cheetah pushes that to you. A program run reaches a lifecycle moment, and Cheetah sends a JSON payload to an HTTPS endpoint you control. Your endpoint turns it into a write against your system of record.

FIG_003 [ EVENT DISPATCH ] SCHEMATIC · JSON OVER HTTPS © CHEETAH SN-4471 INSPECTION CELL scan → analyze → outcome ProgramCompleted POST · application/json MES RECORD SN-4471 PASS flatness 0.04 mm weld seam OK YOUR MES / ERP system of record
▸ FIG_003 — INSPECTION RESULT → MES, VIA EVENT DISPATCH

The model#

Four steps, every time:

  1. A program run reaches a lifecycle moment — it starts, completes, fails, or is cancelled.
  2. Cheetah builds a versioned JSON payload describing what happened and POSTs it to the endpoint URL you registered.
  3. Your endpoint does its work and returns a 2xx.
  4. Cheetah records the delivery. A non-2xx, a timeout, or a connection error is retried within the dispatch window — up to three attempts in about ten seconds — after which the delivery is final and can be replayed manually.

The payload is the same regardless of how many systems subscribe. Register one endpoint for your MES, another for a Slack notifier, another for a data lake — each gets its own copy and its own delivery record.

The events#

Cheetah emits four lifecycle events. Each one carries the run_id, program_id, serial_number, and robot_id so you can route it without a second API call.

Event Fires when What an MES typically does with it
ProgramStarted A program run begins on a part Open an in-process record for the serial number
ProgramCompleted A program run finishes and the QC outcome is computed Write pass/fail and the measured values; advance or quarantine the unit
ProgramFailed A program run stops on a step error Flag the unit as incomplete; alert the line
ProgramCancelled An operator cancels a program run Reconcile the open record; no outcome was produced

ProgramCompleted is the one that carries the inspection result — the passed boolean and the per-check qc_checks array. The other three are state transitions. See the event reference for every field and a full example payload per event.

Event dispatch vs. polling#

React with event dispatch: advance a traveler, quarantine a reject, trip an andon. Reconcile with the open REST API: backfill after downtime, re-query a program run, pull historical results.

Webhooks are the transport today; message-queue transports (NATS, MQTT, Kafka) are on the roadmap and will carry the same payload schema (versioning policy).

Next#

▸▸ /content/developers/event-dispatch.md
▸ DOCS UNDER CONSTRUCTION LAST UPDATED 2026-07-25 ▸ CHANGELOG