Package manifest

One package ships nodes, credential types and workflow templates together — how slugs are namespaced as {org}:{name}, and what versioning means for a workflow already using your node.

A node package is not only nodes. One package can ship three kinds of thing, and the manifest the build produces carries all three:

It ships	Which means
Nodes	Steps that appear in the palette.
Credential types	The typed connection your nodes reference, with its own fields, its auth kind and its own connection test.
Workflow templates	Ready-made workflows built from your nodes, with variables and triggers already in place. Plain data — no executable code.

The three exports are read by the SDK CLI's manifest subcommand: NODES, and optionally CREDENTIALS and TEMPLATES. A package that ships no credential types or templates simply omits them.

Shipping all three together is what makes a package feel finished. A partner installing your integration gets the steps, the credential form that asks for the right fields with the right validation, and a working flow to start from — rather than a handful of nodes and a support conversation about how to wire them.

Slug namespacing

Every node and every credential type is identified as {org}:{name} — a namespace, a colon, a stable slug:

Slugs

acme:hubspot-list-contacts
acme:hubspot          (the credential type)

Rules worth following:

The namespace is yours. Use your organisation, consistently, across every package you ship. revenexx: is the platform's own.
The slug is stable across versions. It is what a saved workflow references, so renaming a slug is not a rename — it is a new node that no existing workflow points at.
Name it for what it does, not for how it does it. acme:orders-export outlives acme:orders-export-v2-rest.

The same namespacing applies to templates the package ships.

Versioning

Two versions matter and they are not the same:

The package version — an ordinary semantic version in package.json. It is what an operator registers, and it is how you ship a fix.

The node version — declared per node in its description. This is the one that reaches a running workflow, because a node instance on a canvas pins the node version it was placed with. A new version of your node does not silently change a workflow that is already running; the author picks it up when they re-place or re-save the node.

That pinning is a promise to your users, so treat a node version like a public interface:

You are	Then
Adding an optional config field, or a new output port	A minor version. Existing workflows keep working.
Fixing behaviour without changing the declaration	A patch version.
Renaming or removing a config field, changing what a port emits, making an optional field required	A major version — and consider whether it should be a new slug instead.

The package.json also carries a human-readable bundle label under a namespaced revenexx group, which is what the palette shows as the group your nodes sit in. Set it; without it your nodes appear under a package name rather than a name a person would recognise.

Integration Studio's node and manifest formats are still settling (v0-draft). Shapes are current rather than final, and a future manifest version may require a rebuild of your package. Keep the source; do not treat a registered tarball as your only copy.

Where to go next

Custom nodes — the node contract and the build that produces the manifest.
Registration — how the package reaches a tenant.
Templates — what a shipped template looks like from the operator's side.
Integration Node SDK — the export arrays and the CLI in full.

Was this page helpful?