Skip to main content

Create a node template from an existing node

POST 
/api/create_node_template/:project_guid/:workflow_guid/:node_guid

Copies an existing node from the acting user's dev clone into a node template on the project's hub, filed under the node's type and a slug made from its name, then commits and propagates the change to every clone.

The whole node comes across - every script it has, its samples, and its library pins - not just its entry-point script. Copying only that file was enough while a node was one Lua script, but a node built from an adapter carries several modules and a library dependency, and a template made from it silently became something that could not run: the extra modules gone, so the first require fails, and its library pins emptied, so nothing would restore them either.

What is deliberately not copied is the files that came from those pinned libraries. Those belong to the pin, and materializing the template puts them back from the version it names; carrying frozen copies as well would mean a template that keeps shipping a library's old code after its pin has moved on.

A template of the same slug is replaced outright rather than merged, and the response says so: names collide once punctuation and case are stripped, so "My Adapter" lands on "my adapter" without the caller having aimed at it.

Samples are the one part the caller chooses, and the default is to leave them out. Every other file in a node is something an author wrote; a sample is a message they captured to test against, which on a live grid is real traffic. A template exists to be reused - by a colleague, in another project, or promoted into a catalog and shipped to customers - so carrying that data along by default would be the wrong way round. Vendors who do want to ship example messages ask for them.

Request​

Responses​

Successful Response