Build an integration
You want Cobblr to talk to a system it doesn't ship with: a self-hosted inventory app, a print-farm manager we haven't packaged, a webcam model that watches for print failures, your own service that should receive Cobblr events. Most of these are a piece of data you install into one workspace, not code anyone has to deploy. The generic engine that runs each kind already ships, and your manifest tells it where to reach the external system and how its records map onto Cobblr's.
That is why a workspace can gain support for a new system without waiting on a Cobblr release. You paste a manifest, it validates, and the running engine interprets it.
The kinds, and which are data
| You want to | Write | Shape |
|---|---|---|
| Pull records from an external app into a workspace | A sync-source manifest | Data (JSON) |
| Drive a REST print/CNC/laser manager | A machine-driver manifest | Data (JSON) |
| Watch a camera frame for print failures | A detector manifest | Data (a small package) |
| Reach a machine the HTTP engine can't express | An edge-bridge driver | Code (a driver package) |
| Deliver notifications to a new transport | A notification channel | Code (in-tree) |
The first three are declarative. A sync source and a machine driver are literal JSON you can paste into a connection form, and a detector is a one-file package that carries a JSON manifest. The last two are code, for different reasons: an edge-bridge driver runs where the hardware is and speaks a protocol (MQTT, binary, a handshake) that no HTTP manifest can capture, and a notification channel is registered in the platform at build time.
What a manifest gives you
Every declarative kind follows the same idea. The manifest names an external
endpoint, an auth header, and a set of small path expressions that read values
out of the JSON the external system returns. A field like "$.state.text" reads
state.text off the response, "='queued'" is a literal, and "={fileId}" fills in
a value the engine already holds. Nothing about the specific vendor lives in the
engine, so adding a vendor is adding a manifest.
That shared expression language shows up in every page here. Learn it once from the machine-driver page and it reads the same in a sync source or a detector.
Where each kind is documented in depth
The concept pages explain what each system does for a user, before you write the integration that extends it:
- Sync sources covers the full manifest shape (references, images, instance targeting, filters). The sync guide is the user's view.
- Digital fabrication covers machine connections and when Cobblr can reach a machine directly.
- Notifications covers the channels that ship today.
- The integration catalog lists the built-in sources, drivers, and detectors you can copy from.
If your target is a machine on a private network that Cobblr can't dial, read edge-bridge drivers and the edge firmware section, which put the adapter next to the hardware.