REST API

Use Project API tokens to call Lleverage's versioned REST API from services, scripts and other programmatic clients.

Lleverage exposes a versioned REST API under https://app.lleverage.ai/api/v1. Use it when a service, script or other programmatic client needs to work with resources inside a Project.

This is different from a published Workflow API Endpoint. A published API Endpoint is an invocation surface for one Workflow. The /api/v1 REST API is the broader Project-scoped programmatic surface used to inspect and use supported Lleverage resources.

Authenticate with a Project API token

Send a Project API token as a bearer token on every request:

curl -H "Authorization: Bearer $LLEVERAGE_TOKEN" \
  https://app.lleverage.ai/api/v1/workflows

Create and revoke tokens under Control → API Tokens. A Project token is scoped to the Project it was created for; the current Project-token surface does not expose narrower per-route scopes.

See API Tokens for the current token permission, expiry, creator-membership and rotation behaviour.

Useful resource families

The public v1 surface includes Project-scoped APIs for resources such as:

• Workflows — list Workflows, inspect versions and executions, and start runs;

• Files — obtain upload and download URLs for Workflow files;

• Knowledge Bases — work with Knowledge Bases and document ingestion;

• Members — inspect Project membership and roles;

• API Tokens — inspect token inventory, identify the current token and revoke tokens;

• Requests — read human-in-the-loop Requests and their saved views.

Other Project surfaces are exposed under v1 as well. Treat the API contract as versioned: do not depend on undocumented internal routes outside /api/v1.

List Workflows

GET /api/v1/workflows returns Workflows in the token's Project.

curl -s \
  -H "Authorization: Bearer $LLEVERAGE_TOKEN" \
  https://app.lleverage.ai/api/v1/workflows

Project scoping happens server-side. A resource outside the token's Project is generally returned as 404, so a not-found response can also mean the resource is outside the token's scope.

Run a Workflow

Start a Workflow with:

POST /api/v1/workflows/{workflowId}/run

The request accepts an inputs object. Runs default to the test environment; pass "environment": "production" when you intend to run the active published production version.

curl -X POST \
  -H "Authorization: Bearer $LLEVERAGE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "environment": "production",
    "inputs": {
      "orderId": "12345"
    }
  }' \
  https://app.lleverage.ai/api/v1/workflows/$WORKFLOW_ID/run

A production run requires a published production version. Do not send versionId, sessionId, resumeId or uiNodeId unless you are integrating against those specific contracts; they are not needed for the basic start-a-Workflow case.

A run response may be an event stream or a JSON response for outcomes resolved before streaming begins. Read the response Content-Type rather than assuming every successful or unsuccessful run response is an event stream.

Errors and retries

Authentication failures return 401. Several invalid-token conditions intentionally collapse to the same Token is invalid response rather than exposing detailed authorisation state.

The public API does not currently provide general idempotency handling. Do not blindly retry state-changing requests. Repeating a mutating POST can repeat the operation, including starting a Workflow twice. For reads, normal client retry behaviour is safer; for writes, make retry decisions based on the specific operation and the response you received.

Keep the two API surfaces distinct

Use REST API when your integration needs Project-scoped programmatic access to Lleverage resources.

Use a published Workflow API Endpoint when another system only needs to invoke that published Workflow through the endpoint generated from its API Call trigger.

This distinction keeps the Project API contract separate from a Workflow's published invocation contract.