Developers

Under construction: the two approaches below are ready to build against today. Pages marked ▸ STUB in the sidebar aren't yet — the changelog tracks what lands next.

A Cheetah integration uses one of two approaches, and most production systems use both:

• Event dispatch — Cheetah pushes lifecycle events to your systems in real time.
• Request/response — you query the open REST API on your own schedule.

Data is the boundary#

The architectural boundary between Cheetah and your systems is data: the lifecycle events Cheetah pushes, and the documented responses the open REST API returns. Everything on Cheetah's side of that line is Cheetah's to run and evolve. Everything on your side is yours.

The split is what makes an integration durable:

• Your side is yours. Build the receiver in whatever language your team works in, host it however you host things, orchestrate it however your architecture demands. Cheetah has no opinion past the handoff.
• Both sides evolve independently. Replatform, migrate, swap your MES — you update your receiver and the handshake with Cheetah doesn't move. When Cheetah evolves, events and API responses stay governed by the versioning policy, so it doesn't move underneath you either.
• Ownership is unambiguous. The team that owns the systems behind a receiver owns the receiver — they can build it against internal infrastructure, test it against real systems, and respond when it misbehaves on a night shift. A receiver maintained at arm's length from its systems is one nobody can fix quickly.

So the receiver and the API client belong on your side of the line.

Event dispatch — real time#

Cheetah pushes a signed event to an endpoint you control the moment a program run starts, completes, fails, or is cancelled. This is how you get an inspection result into an MES, ERP, or quality system without polling and without a human re-keying a measurement. It's the right tool when you need to react to a part as it comes off the line.

→ Event dispatch · Webhooks · Event reference

REST — request and response#

You call the API when you need data on your own schedule: reconciling after downtime, backfilling history, re-querying a program run you already processed, or pulling results for a report. It's the right tool when you need to reconcile, not react.

→ API reference · Open REST API · SDKs

Using both#

Event dispatch drives the line in real time; a periodic poll of the API catches anything a delivery missed and reconciles your records against Cheetah's. A robust integration treats dispatched events as the live signal and the API as the source of truth to fall back on.