Docs for AI Agents

This section is written for AI agents, not people. It is hidden from the docs menu, but it is listed in llms.txt and comes first in the agent's docs search.

Each page sticks to facts an agent needs to call the Fluxify tools correctly: fields, rules, limits, defaults, common errors and JSON examples. It never describes clicks or screens.

How to read these pages

Search with search_docs, then open a page with read_doc. With no heading, read_doc lists the page's sections; pass one of them as the heading to read just that section.

Start here

• Canvas guide: how a canvas runs, block handles and edges, get_block_schemas, edit_canvas with validation, errors and saving a block output to a variable. Read it before you build or edit any canvas.

Resource pages

One page per thing you can save with the tools.

• Route reference: an HTTP endpoint. Fields, path rules, request schemas, content types and errors for save_route.
• Workflow reference: a background job. Fields, timeouts, what it receives and errors for save_workflow.
• Trigger reference: what starts a workflow. Cron and interval schedules, queue sources, batching and errors for save_trigger.
• Custom block reference: a reusable block with your own code. Input parameters, usage kinds, writing the code and errors for save_custom_block.
• Middleware reference: a chain of custom blocks run before or after routes. Run order and errors for save_middleware.
• Integration reference: a connection to a database, KV store, AI provider or queue. Config for every variant, cfg: secrets and errors for save_integration.
• App config reference: project settings and secrets. Encryption, encoding and errors for save_app_config.
• Test suite reference: saved requests or inputs with assertions. Assertions, hooks, overrides, running and errors for save_test_suite.

Block inputs

• Dynamic values and js: expressions: how a block input becomes dynamic. The js: prefix, what names exist, which fields accept it and the common mistakes. Read it before you fill any block field.

Recipes

Each recipe is a list of steps. Every step is a tool call with its arguments.

• Validate a request: reject bad input with the route's body, query and params schemas, not regex in a block.
• Composed flows: check then update or 404, retry a flaky call, an error handler returning JSON 500, a response status set at run time.
• Route with JWT auth: a route that answers 401 unless the request has a valid token.
• Debug and fix a route or workflow: read the debug error from call_route, check the logs, record a run if needed, fix and re-run.
• Workflow with a cron trigger: a background job that runs on a schedule.
• Write and run a test suite: save a suite, run it, read the result, trace a failure.
• Use an integration in a canvas: a database integration with its secret, read from a route.
• Inspect data with DB Native in a sandbox: look at rows in your own private sandbox on development data, with call_sandbox, without making a route.
• Try blocks with an ephemeral run: run a few blocks in one run_blocks call on development data, and keep nothing.
• Plan and work through a big job: suggest plan mode for a big request, write the plan, then work through it with update_todos.
• Debug a route in a sandbox: copy a route into your own sandbox with copy_blocks, fix it there on development data, and copy the fix back.

Replying

• Referring to resources in chat: link an existing route, workflow or other resource in your reply with :ref[Label]{type=route id=...}.

Rules that apply to every tool

• Tools act as the signed-in user. A You need the ... role error means ask a project admin. Do not retry.
• A save_* tool creates when you leave out the resource id, and updates when you pass it. On update, send only the fields that change.
• A new route or workflow is on in development (devActive, on by default) and off in production (active). Pass active: true when it is ready for production, then promote a committed version with promote_version: production serves only a promoted version, and a person approves every promote. A new trigger is inactive: switch it on with active: true.
• A block text input is a literal unless it starts with js:, and js: code must return the value. Never use . See Dynamic values and js: expressions.
• Put secrets in app config and refer to them as cfg:KEY in an integration, or with getConfig("KEY") in code. Never write a secret into a block or a canvas.
• Check get_system_logs after a change. Compile errors show up there.