Flow Builder

Flow Builder lets you connect the building blocks of a lending decision into one automated process on a visual canvas. A flow can call an integration, run a decision tree, branch on the result, price offers, wait, send an email, and notify your systems, all in order. Flows are versioned like decision trees: you edit a draft, test it, publish it, and choose which version is live. Every run is recorded so you can see the exact path an application took.

📘

Beta

Flow Builder is marked Beta in the dashboard sidebar.

Key concepts

• Trigger: how a flow starts. Every flow has exactly one.
• Node: one step on the canvas. Nodes are connected by edges that set the order.
• Inputs: the variables the trigger expects. They become the request body for API runs.
• Draft: the editable version. Saving changes updates the draft.
• Live version: the published version that new runs use.
• Run: one execution of a flow. Each run is tied to an application.
• Execution path: the ordered list of nodes a run passed through, with status, timing, inputs and outputs.

How flows work

Triggers

• API: your system starts the flow by calling its run URL with the trigger's inputs. A new application is created for each run.
• Application: the flow runs for an existing application and reads that application's data. Use it as part of an application journey.

Once an Application-trigger flow is published, you can add it to an application journey in Product Studio: select a page, and in Page Settings → On Continue, choose the flow in the Initial Provider or Final Provider list.

Node types

The palette groups nodes into three categories.

Webhook nodes.

curl -X POST "https://app.lendapi.com/flow/wait-webhook/3f6c2a9e-8d1b-4b7e-9a51-0c2d4e6f8a10/" \
  -H "Authorization: Bearer test_xxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{ "app_id": "9b2f7c1e-1111-4a2b-8c3d-555501000000", "verification_status": "passed" }'

Flow lifecycle

stateDiagram-v2
    [*] --> Draft: Create flow
    Draft --> Draft: Save draft / Test flow
    Draft --> Published: Publish (validates first)
    Published --> Draft: Edit again or Restore As Draft

• Publishing validates the flow. If there are errors, publishing is blocked and the Warnings checklist shows what to fix.
• Inactive flows don't run. API calls return "Flow is not active." and test runs are blocked.
• Delays and webhook waits run in the background. An API run that reaches one returns right away with status scheduled.

Build and manage flows

Build and publish a flow

1. Go to Workflows → Flow Builder and click + Flow.
2. In New Flow, enter a Name (for example "Personal Loan Flow") and an optional description.
3. On the empty canvas, choose a trigger (API or Application) and select its Inputs. For API triggers the panel also shows the API URL.
4. Add nodes from the palette. Click a node to configure it in the side panel; use Swap node to change its type.
5. Connect each branch to the next step and finish paths with End.
6. Click Save draft regularly.
7. Click Test flow. For an API trigger, enter input values. For an Application trigger, Select an application to run against. The test panel shows each node's result, the Branch taken, and output variables. A test run never changes the real application.
8. Click Publish. In Publish Flow, enter a Description and tick Set as live version if new applications should use it right away.

The Versions tab lists every version. Click Set Live to switch the live version, or Restore As Draft to copy an older version into the draft.

Monitor and manage runs

Open an application in the Agent Dashboard. In the Overview panel, the Flow field shows which flow and version ran, and Flow Preview opens the run.

• See the execution path: click Flow Preview. Visited nodes are highlighted. Click a node to see its status, runtime, input and output. Statuses include Completed, In Progress, Failed and Suspended.
• Skip a delay: in Flow Preview, click Skip delay on the waiting Delay node. The flow continues immediately and the override is recorded.
• Suspend a run: while a run is in progress, click Suspend Run and confirm. The run stops before its next step.
• Re-run: with the application's Underwriting tab open, click the re-run icon next to Flow Preview and confirm Re-run Flow. The same version runs again using the application's current data, and the current outcome is replaced with the new result. You can't re-run while the flow is still processing.

A suspended run does not resume on its own. To run the flow for that application again, use Re-run.

Run flows via the API

The flow's API tab shows the run URL and a ready-to-copy cURL command with your trigger inputs. Authenticate with Authorization: Bearer <your API key>. Keys that start with live_ run in your Production environment; keys that start with test_ run in your Sandbox.

Example: run an API-trigger flow

curl -X POST "https://app.lendapi.com/flow/3f6c2a9e-8d1b-4b7e-9a51-0c2d4e6f8a10/run/" \
  -H "Authorization: Bearer test_xxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{ "params": { "first_name": "Jane", "last_name": "Doe", "email": "[email protected]", "requested_loan_amount": 15000 } }'

{
  "flow_id": "3f6c2a9e-8d1b-4b7e-9a51-0c2d4e6f8a10",
  "version": 4,
  "app_id": 120045,
  "app_session": "9b2f7c1e-1111-4a2b-8c3d-555501000000",
  "status": "success",
  "env": "test",
  "result": { "offer_amount": 15000 }
}

result contains the flow's output variables. status is success, failed (with an error message) or scheduled (with flow_resume_at) when the flow is waiting on a delay or webhook. Missing required inputs return HTTP 400 with a missing_inputs list. Inputs the flow does not declare are accepted and listed in unrecognized_inputs.

🚧

Check status, not just the HTTP code

A run that fails inside the flow still returns HTTP 200 with "status": "failed". Always check status, not just the HTTP code.

Access and best practices

Permissions

Designing, testing and publishing flows requires the Flow Builder module. Viewing a run's execution path, suspending, skipping delays and re-running are application actions controlled by the Agent Dashboard module. See Roles and Permissions.

Best practices

• Test every branch, including timeouts and failure paths, before publishing.
• Keep secrets out of payloads. Send only the variables your endpoint needs.
• Make your webhook endpoints idempotent using the Idempotency-Key header, because retries can deliver the same event twice.
• Use Parallel Run for independent calls (for example two bureaus) to cut run time, and set a sensible Max wait time.
• Prefer Re-run over manual edits when application data changes, so the decision and its audit trail stay consistent.
• Resolve warnings early. The Warnings checklist on the canvas shows setup problems, such as missing variables, that block testing and publishing.

Related guides