YepCode Run

YepCode Run executes JavaScript and Python with npm and PyPI dependencies on a serverless platform. Workflows create and publish processes, run them synchronously or asynchronously, read execution logs, and manage schedules, modules, variables, and object storage.

Verified 56 actions Session available

YepCode Run website Platform Documentation Capability data verified 2026-08-25

A dependency upgrade is requested for code that scheduled jobs already run

Get Team Dependencies returns the team's current manifest for that language

Update Team Dependencies stages the new manifest, which installs nothing on its own

List Processes and List Schedules name every process and job the shared runtime carries

The agent posts the manifest diff beside the processes it would land on

The owner chooses between Install Team Dependencies and Discard Dependency Installation

What This Integration Enables

Every automation platform eventually meets a step nothing in the catalog covers: a proprietary file format, a vendor SDK with no REST surface, a transformation that is genuinely easier to express in twenty lines of Python than in any visual form. The usual answer is a script on a server somebody set up two years ago. YepCode Run is the better answer, because it treats that code as a first-class object. A process has source, a parameter schema, published versions, and moving aliases, and it runs on infrastructure that installs npm and PyPI dependencies without anybody maintaining a container.

That structure is what makes it worth reaching from a flow rather than shelling out. FlowRunner agents execute a process and wait, or execute it in the background and let YepCode call back when it finishes. They read the return value, and when it does not make sense they read the logs, which is where a failure actually explains itself. This connector's own vocabulary is unusually honest about the gap that matters: a completed status means the process ended, not that it succeeded, because code that caught its own error and returned normally reports exactly the same thing. Those are automation exceptions in their purest form, and a flow that reads only the status will never see them. Aliases, schedules, sandboxes, team variables, and object storage are all here too, and so is the one operation whose blast radius reaches every process the team owns.

Without FlowRunner

The escape hatch is somebody's laptop The one step no connector covers becomes a script run by hand, with no version, no log, and one person who understands it

Production runs whatever was last saved A job that names no version executes the draft somebody was in the middle of editing

A finished job explains nothing The run reports that it ended, and whether it actually worked is a separate investigation

With FlowRunner

Custom code is a governed asset Logic lives as a named process with published versions and a moving alias that production points at

Promotion is a repoint, not an edit Moving the alias switches every caller to the new code without a single flow being touched

Every run leaves a trace Status, return value, and complete logs are readable from the flow that started the run

Use Case Scenarios

The step no connector covers, without a server nobody owns

A nightly reconciliation needs a transformation that no visual step expresses cleanly. The logic lives as a YepCode process, published under a version tag and pointed at by an alias named for production. The flow calls Execute Process with a callback URL, so YepCode posts back when the run finishes rather than being polled for ten minutes. The agent reads Get Execution for the return value, and because a completed run is not automatically a successful one, it also reads Get Execution Logs whenever the return value does not match the expected shape. Clean results are written to Snowflake; anything unexplained goes to the data owner in Slack with the log excerpt attached rather than a status code.
Shipping a change to shared logic without editing a single flow

An engineer changes a process's code with Update Process, which edits the draft and changes nothing that is running. Publish Process Version freezes it under a tag. Then Update Process Alias repoints the production alias at the new version, and every flow naming that alias picks it up on its next execution. Nothing in FlowRunner was edited, no connector was reconfigured, and the previous version still exists to point back at. The same ladder works for modules, so shared code used by many processes is promoted once rather than copied into each of them.
One place where every failure lands

Update Team sets an error handler process, which YepCode runs whenever any other process fails. Rather than error handling written separately into every job, one process receives them all, and it is pinned to a published tag because the thing that handles failures is a poor candidate for running a draft. That handler writes the failure to a table, and the FlowRunner flow watching that table opens a ticket, pages the right owner, and attaches the logs. On the operational side the agent uses List Executions filtered to failures over a window as a cheap health read, and Rerun Execution to retry a job with its original input rather than reconstructing the parameters by hand.

Human-in-Loop Highlight

YepCode splits a dependency change into two operations, and that split is the gate. Update Team Dependencies replaces the team's manifest and installs nothing. Install Team Dependencies applies it, rebuilding the runtime image for every process in the team at once. Discard Dependency Installation throws the staged change away. So a package left out of a hand-assembled manifest is removed from every process that was using it, a version bump can break jobs nobody in this conversation has ever read, and the breakage does not appear at install time. It appears at those processes' next execution, which for a nightly job means at three in the morning, to somebody else. The vendor built the pause; this connector's job is to use it. So the agent stages, gathers, and stops. It posts: "Staged manifest adds one package and bumps two. Three packages present in the current manifest are absent from the staged one and would be removed. 14 processes and 6 schedules run on this runtime, including the nightly settlement job. Install, or discard?" The owner decides. Staging the change, diffing the manifests, and listing everything downstream is machine work. Rebuilding a runtime that other people's jobs depend on is not.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

56 actions

Processes

List Processes Returns the team's processes, YepCode's named and versioned units of code.
Get Process Returns one process with its source, parameter schema, and settings. It accepts a slug as well as an id, and the slug is the identifier that stays stable across environments.
Create Process Creates a process from source code. Dependencies are not inferred from the code unless auto-detect is on, so a package missing from the manifest is simply absent at run time.
Update Process Changes a process's code, schema, settings, or tags. This edits the draft. Executions that name a version keep running the published code, which is the point and also the thing that surprises people.
Delete Process Removes a process. Its schedules stop and its webhook endpoint stops answering, so anything calling that URL starts failing immediately.

Versions and Aliases

List Process Versions Returns a process's published versions with their tags.
Publish Process Version Freezes the current code as a tagged version. This is what makes an execution reproducible, because a run that names a tag is pinned to code that cannot change under it.
Get Process Version Returns one published version, including the exact code it pinned.
Delete Process Version Removes a published version. Any schedule or execution naming its tag stops working, and an alias pointing at it is left dangling.
List Process Aliases Returns a process's aliases. An alias is a moving name pointing at a fixed version, which is how a flow refers to code without naming a specific release.
Create Process Alias Points a moving name at a fixed version. How a promotion happens without touching a flow.
Update Process Alias Repoints an alias at a different version. This is the deploy: every execution naming the alias switches to the new code on its next run.
Delete Process Alias Removes an alias. Executions that named it start failing rather than falling back to a version.

Executions

Execute Process Starts a process and returns an execution id immediately. The safe default for anything that might take more than a few seconds, and it accepts a callback URL so YepCode reports completion instead of being polled.
Execute Process Synchronously Runs a process and holds the call open until it finishes, returning the result. Right for a short transformation whose output the next step needs, and wrong for a long job, where it produces a timed-out flow with the execution still running.
List Executions Returns executions with filters on process, status, time range, and comment. Filtering to failures over a window is the cheapest health read this connector offers.
Get Execution Returns one execution with its status, timeline, and return value. A finished status means the process ended rather than that it succeeded, so the return value is what gets read.
Get Execution Logs Returns everything the process printed. This is where a failure actually explains itself: the stack trace, the failed call, and the missing dependency are here and nowhere else.
Rerun Execution Runs a past execution again with its original input. The quickest retry that does not involve reconstructing parameters by hand.
Kill Execution Stops a running execution where it stands. Anything half-written stays half-written, so it is aimed at runaway jobs rather than used as a general cancel.

Schedules

List Schedules Returns the team's scheduled processes with their cron expressions and state.
Get Schedule Returns one schedule with its expression, input, and paused state.
Schedule Process Sets a process to run on a cron expression or once at a fixed time. Whether concurrent executions are allowed is the field that decides how a slow run behaves when the next tick arrives, and both answers fail quietly.
Update Schedule Changes a schedule's expression, concurrency rule, or input.
Pause Schedule Stops a schedule firing without deleting it. The right way to suspend a nightly job during a migration, because deleting loses the expression and the input.
Resume Schedule Starts a paused schedule firing from its next tick. Ticks missed while it was paused are not made up.
Delete Schedule Removes a scheduled process along with its expression and input.

Modules

List Modules Returns the team's reusable code modules, which processes import rather than duplicating logic.
Get Module Returns one module with its source.
Create Module Creates a reusable module. Modules are versioned and aliased exactly like processes, so shared logic is promoted on its own schedule.
Update Module Changes a module's name or code. Like a process, this edits the draft, and processes importing a published version keep the old code until they are repointed.
Delete Module Removes a module. Every process importing it starts failing at run time with an import error, and nothing warns in advance which processes those are.
List Module Versions Returns a module's published versions with their tags.
Publish Module Version Freezes a module's current code as a tagged version so importing processes can pin to it.
List Module Aliases Returns a module's aliases, the moving names importing processes can pin to.
Create Module Alias Points a moving name at a fixed module version, so shared logic is promoted without editing the processes that import it.
Update Module Alias Repoints a module alias. This is a deploy of shared code: every importing process picks it up on its next run.
Delete Module Alias Removes a module alias. Processes importing it start failing rather than falling back to a version.

Variables

List Variables Returns the team's environment variables, which every process can read. Values marked sensitive come back hidden.
Create Variable Adds an environment variable available to every process in the team. Anything secret is marked sensitive, because otherwise the value is readable in the listing and the interface.
Update Variable Changes a variable's key or value. Processes pick the new value up on their next execution rather than immediately.
Delete Variable Removes a variable. Processes reading it get an undefined value on their next run, which usually surfaces as a confusing runtime error rather than a clear configuration one.

Storage

List Storage Objects Returns the files in the team's object storage, optionally under a prefix. Storage is how one process hands a file to the next.
Upload Storage Object Uploads a file into object storage from a URL. The destination filename is the whole key, so a name containing a path creates the folder structure implicitly.
Download Storage Object Downloads a file into FlowRunner's own file storage and returns its URL, which keeps the file inside the flow rather than behind a public link.
Delete Storage Object Removes a file from object storage. There is no undelete and no versioning.
Create Signed URL Returns a time-limited URL for a storage object that needs no YepCode credentials. How a file reaches somebody outside the team, and a link anyone holding it can use until it expires.

Sandboxes

Create Sandbox Starts a long-lived isolated container an agent or a session can keep working in, rather than a one-shot execution.
Update Sandbox Changes a running sandbox's timeout, which is how a session is kept alive past its original window. Extending it extends the bill.
Kill Sandbox Stops a sandbox immediately and stops its charges. Run at the end of any flow that creates one, because a sandbox nobody stopped keeps billing until its timeout.

Team

Get Team Returns the team's settings, including its zone, schema validation switch, and error handler. The cheapest way to confirm the connection is pointed at the right team, since a wrong team id makes everything merely look empty.
Update Team Changes the team's name, parent teams, schema validation, or error handler. Naming an error handler process gives every failure in the team one place to land, instead of error handling written into each process separately.
Get Team Dependencies Returns the team-wide dependency manifest for a language. The read that a staged change is diffed against.
Update Team Dependencies Replaces the team-wide manifest. It stages the change and installs nothing, which is what makes a review possible before anything is rebuilt.
Install Team Dependencies Applies the staged manifest, rebuilding the runtime for every process in the team at once. The operation this page's human gate exists for.
Discard Dependency Installation Cancels a staged change before it is installed, leaving the current runtime untouched. The other half of the gate, and the reason staging is not a commitment.

Frequently Asked Questions

What can FlowRunner do with YepCode Run?

FlowRunner agents can run List Processes, Get Process, and Create Process in YepCode Run, plus 53 more actions.

Does connecting YepCode Run to FlowRunner require OAuth?

No. YepCode Run connects to FlowRunner with session-based authentication, no OAuth flow required.

Can YepCode Run trigger a FlowRunner workflow automatically?

YepCode Run doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with YepCode Run

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us