Publishing a Workflow
Workflows are built in the Runway app and published to a Runway Dev project. Publishing requires a one-time link between a Runway app workspace and your project.
Link a Runway app workspace
Section titled “Link a Runway app workspace”A workspace can be linked to one Runway Dev project. Linking takes an admin on each side: an admin of the project creates the code, and an admin of the workspace uses it.
- In the Developer Portal, open Manage, then Connections. Under Link Runway app account, choose Get started (or Link a new workspace if one is already linked) and copy the one-time code. It expires after six hours.
- In the Runway app, open Workspace Settings, choose Link under Developer account, and paste the code. On Enterprise plans, link from Organization Settings instead; see Linking Developer and Web App accounts.
Once the accounts are linked, workspace Editors and Admins can publish Workflows to the project. Run them with an API key from that project.
Publish an endpoint
Section titled “Publish an endpoint”Build and test the Workflow in the Runway app; see Introduction to Workflows. Then choose Publish, then Publish new endpoint, and choose which inputs and outputs the endpoint exposes. Only exposed outputs appear in an invocation’s output. If publishing fails because the Workflow uses assets from another workspace, clone the Workflow into your own workspace and publish the clone.
Hiding an input only removes it from the Developer Portal’s form. Its value can still be read from GET /v1/workflows/{id} and set in a request.
Find it in the Developer Portal
Section titled “Find it in the Developer Portal”Open Workflows in the Developer Portal. Each Workflow lists its published versions by Endpoint ID. A version’s page shows each exposed input’s label and node ID, a form to run the version with test inputs, and Get code with cURL, Node.js, and Python samples. Requests address inputs by node ID; see Running a Workflow.
Versions
Section titled “Versions”To update your integration, publish the Workflow again, test the new version, and then change the ID your integration calls. Keep the ID in configuration rather than in code so this doesn’t require a release.
Earlier versions stay available: GET /v1/workflows lists every published Workflow with its versions, newest first.