Running a flow from your own code (the API)
A personal token and one endpoint: list flows, start a run of up to 20 items, poll the result — the same interface Claude uses when you connect FlowArray as a tool.
In this article (5)
For your own scripts and agents — as opposed to a third-party sender — you do not need a trigger at all. FlowArray exposes one JSON-RPC endpoint that speaks the Model Context Protocol, and a personal token is all it takes.
Get a token
Settings → MCP access → create a personal API token. It looks like fa_… and is shown once.
A token acts as you, with your role, so it can do what you can do — build, run, read results. Revoking it cuts access immediately. That breadth is why a token is for your code and a trigger is for anything you do not control.
Start a run
POST https://flowarray.app/api/mcp
Authorization: Bearer fa_…
{ "jsonrpc": "2.0", "id": 1, "method": "tools/call",
"params": { "name": "run_workflow",
"arguments": { "workflow_id": "<id>", "items": [ { "product_name": "Kettle" } ] } } }It returns the run id. Up to 20 items per call.
What else is there
| Tool | Does |
|---|---|
list_workflows | Find a flow (and its id) by name |
get_workflow | Inspect one flow's shape |
run_workflow | Start a run, up to 20 items |
list_runs | Recent runs |
get_run | Poll a run's status, items and outputs |
create_workflow | Create a draft flow — see the note below |
Two safety properties worth relying on
- A created flow cannot spend.
create_workflowproduces a draft with no pools attached, so it runs in free test mode until a person opens it in the Builder and points it at real keys. Automated authoring can never quietly start paying providers. - Every run still obeys the workspace's daily spend limit and each pool's and key's own ceilings. The API is not a way around them.
Same endpoint, friendlier front door
This is the identical endpoint Claude talks to when you connect FlowArray as a tool server — see chatting with FlowArray, which uses a browser sign-in instead of a pasted token.