Skip to main content
The SuperFlow API lets you manage the full lifecycle of a SuperFlow workflow programmatically. It covers workflow definitions (create, read, update, delete, validate, lock, and share), versions (save the draft as a version and choose which version production runs), executions (run, monitor, pause, resume, terminate, and rerun), schedules (recurring cron-driven triggers), and approvals (human-in-the-loop requests raised by running workflows). The node catalog describes every node type you can use.

​
Base URL

All endpoints in this section are served from the following base URL.

​
Authentication

Every request needs a valid Lyzr API key in the x-api-key header. Studio session keys (prefixed agk_ or ags_) and durable sk- keys are accepted.
Your identity comes from the key. The x-org-id and x-user-id headers are accepted only when they match the key’s owner, and a header that contradicts the key is refused with 403. A header the key cannot vouch for is ignored, so you cannot use a header to act as another user. Two requests do not need an API key:
  • A request to Execute Workflow that carries an X-Webhook-Secret header matching the workflow’s webhook trigger. The run executes as the workflow’s owner.
  • A request to Get Node Catalog.
The API returns the following authentication errors:

​
Request limits

The following limits apply to every request under /api:
  • Requests are limited to 50 per second per client IP address. Over the limit, the API returns 429.
  • Request bodies are capped at 8 MiB.
  • The HTTP Request node refuses a response larger than 16 MiB, and any node whose output exceeds 16 MiB fails.
  • Every URL a workflow calls must resolve to a public address. This covers the HTTP Request url, a Parse or Extraction file_url, the A2A Agent agentUrl, a Guardrails endpoint, an OAuth2 token_url, and the endpoint of a bring-your-own-model credential. Loopback, private-network, and link-local addresses are refused, and so is a redirect to one.

​
Drafts and versions

A workflow has two graphs. The draft, also called the test graph, is what you save with Update Workflow and what the Studio canvas runs. A version is an immutable snapshot of the draft, and the live version is the one production runs. Saving only changes the draft, so production keeps running the live version until you deploy a new one. A workflow that has never had a version deployed keeps running its draft.

​
Typical flow

A common integration follows four steps. First, create a workflow with Create Workflow or build it visually in Studio; the workflow graph itself is a JSON document described in the flow_data reference. Check it with Validate Workflow, then save a version and deploy it when it is ready for production. Second, start a run with Execute Workflow, which returns an execution_id immediately. Third, track progress by polling Get Execution Status or by subscribing to the live event stream. Fourth, if the workflow contains a human-in-the-loop node, resolve the pending request with Resolve Approval so the run can continue.

​
Access control

Workflows are owned by the API key that created them. You can share a workflow with users or teams at read, write, or execute access, or with your whole organization at read or write. List endpoints return resources you own plus resources shared with you. Destructive operations such as deleting a workflow or removing its shares are restricted to the owner. The owner can also lock a workflow. While it is locked, a shared editor cannot save, publish, or deploy it, and those requests return 423. Saving a version and deploying need edit access, and listing and viewing versions need read access.

​
Next steps

If you are new to SuperFlow, start with the SuperFlow overview and the quickstart to build your first workflow, then return here to automate it over REST.