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; 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; 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; "={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.