Pipelines, models and runs, from code or an agent.

The API is an MCP server at https://slai-api.flybywire.se/mcp (Streamable HTTP, stateless). Any client that speaks MCP over HTTP connects to that address. No key is needed: the client sends you to the slai studio, where you sign in the way you made your account (Apple, Google or a password) and approve the connection (OAuth 2.1 with PKCE, the protocol's own authorization). The connection then appears under Settings → API & agents in the studio, named after the client, and is disconnected there like any key.

Claude (claude.ai, Claude Desktop)

Settings → Connectors → Add custom connector, paste https://slai-api.flybywire.se/mcp, then Connect and sign in.

Claude Code

claude mcp add --transport http slai https://slai-api.flybywire.se/mcp

Claude Code opens the sign-in the first time you use a tool (/mcp shows the status). To skip the sign-in, on a server or in CI, pass a key instead:

claude mcp add --transport http slai https://slai-api.flybywire.se/mcp \
  --header "Authorization: Bearer slai_your_key_here"

Cursor, Codex, ChatGPT and others

Anything that takes an HTTP MCP server. Sign-in happens on connect when the client supports OAuth; otherwise add the header:

{
  "mcpServers": {
    "slai": {
      "type": "http",
      "url": "https://slai-api.flybywire.se/mcp",
      "headers": {"Authorization": "Bearer slai_your_key_here"}
    }
  }
}

As a skill

Agents that work from instructions rather than tools (a Claude Code skill, a Codex AGENTS.md, a system prompt) can load https://slai-api.flybywire.se/docs/skill.md: the same rules and endpoints as a Markdown skill that reads the key from SLAI_API_KEY. Save it as .claude/skills/slai/SKILL.md (or wherever your agent keeps skills), put the key in the environment, and the agent knows how to use slai.

Tools

On connect the server hands the agent the pipeline rules below as its instructions, then offers these tools:

Every tool runs the matching REST endpoint in-process, so validation, pricing and error messages are identical whichever way you call. Files included: upload_file takes the bytes as base64 or a public https url and runs the same upload as POST /v1/files; for real files on disk, begin_upload hands back a presigned PUT url so the bytes go straight to storage from the shell, and finish_upload makes the file ready.

For your own code, or an agent without a browser: create a key under Settings → API & agents in the studio, or Settings → API keys in the app. It is shown once. Send it on every request:

Authorization: Bearer slai_your_key_here

A key, and a signed-in agent, acts as the account behind it: the pipelines it makes are that account's, the runs it starts spend that account's balance and show up in the Runs tab. Neither can mint or revoke keys, add funds, or publish to Discover. Those stay in the app and the studio, so a leaked key is contained. Revoke it there if it leaks.

curl https://slai-api.flybywire.se/v1/balance -H "Authorization: Bearer slai_your_key_here"

Answers with balance_usd and topup_url, the page where the account's owner adds funds by card (?amount_usd=25 preselects an amount). A run or draft the balance cannot cover is refused with 402 before anything starts, and the error carries the same topup_url; an agent hands it to you. Agents cannot add funds themselves.

1 · Browse the catalog

curl "https://slai-api.flybywire.se/v1/models?view=summary&output=image" \
  -H "Authorization: Bearer slai_your_key_here"

Filters: provider, input, output (a type: text, image, audio, video, document, web, archive), available=true. view=summary leaves out the long descriptions and option schemas; GET /v1/models/{id} has everything for one model.

2 · Create a pipeline

curl -X POST https://slai-api.flybywire.se/v1/pipelines \
  -H "Authorization: Bearer slai_your_key_here" \
  -H "Content-Type: application/json" \
  -d @pipeline.json

The body is validated against the catalog; a 422 says exactly what to fix. The answer carries the pipeline's id and total_cost_usd per run. GET /v1/pipelines/{id}/spec shows the run contract: the inputs a caller must send, the options open to them, and an example request.

3 · Run it

curl -X POST https://slai-api.flybywire.se/v1/pipelines/PIPELINE_ID/executions \
  -H "Authorization: Bearer slai_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{"inputs": {"brief": {"type": "text", "text": "a lighthouse at dawn"}},
       "step_options": {"paint": {"size": "1024x1024"}}}'

The API answers 202 at once with the execution; the price is reserved from the balance up front and the run continues server-side whether or not you keep watching.

4 · Read the result

curl "https://slai-api.flybywire.se/v1/executions/EXECUTION_ID?wait=60" \
  -H "Authorization: Bearer slai_your_key_here"

?wait= holds the request until the run has completed or failed, up to 120 seconds, and returns the latest snapshot either way: one call instead of a polling loop. GET /v1/executions/{id}/events streams the same snapshots over SSE. Results sit under results[step_id].outputs, and the outputs a pipeline names as its deliverables come back under deliverables as well. Binary outputs carry a file_id and a presigned url that expires after about an hour.

{
  "name": "Poster maker",
  "description": "A one-line brief becomes a poster",
  "steps": [
    {
      "step_id": "write",
      "name": "Write the image prompt",
      "model_id": "google-gemini-pro",
      "input_sources": {
        "text": {
          "pre_input": "Write one vivid, specific image prompt for this brief:\n",
          "sources": [{"step_id": "", "output_key": "brief"}]
        }
      }
    },
    {
      "step_id": "paint",
      "name": "Paint it",
      "model_id": "openai-image",
      "input_sources": {
        "text": {"sources": [{"step_id": "write", "output_key": "text"}]}
      },
      "options": {
        "size": {"ask": true, "default": "1024x1536", "note": "Pick the canvas"}
      }
    }
  ],
  "input_meta": {
    "brief": {"label": "Brief", "help": "What should the poster show?"}
  }
}

• Steps run in array order. Each step has step_id (^[a-z0-9_-]{1,50}$), model_id (a catalog id), input_sources, and optional name and options.
• input_sources has one entry per input TYPE the model declares — the key is the type name ("text", "image", "audio", "video", "document"), the value is {"sources": [...]} with an optional "pre_input" (text inputs only: hidden text placed before the joined sources).
• A source is exactly one of: an earlier step's output {"step_id": "<earlier step>", "output_key": "<that step's output type>"}; a run input the caller supplies at execution time {"step_id": "", "output_key": "<input name>"}; a fixed text value {"value": {"type": "text", "text": "..."}} (bake prompts and instructions in here); or a baked file {"value": {"type": "image|audio|video|document", "file_id": "..."}} — a file the account uploaded that every run reuses (a driving clip for motion transfer, a style frame, a logo), so runners never supply it. Only reference file_ids that exist on the account.
• Types line up exactly: an image input needs an image source. Text inputs may fan in several sources (joined in order); binary inputs take one source unless the model's multi_inputs allows more (then order matters, e.g. clips join in wiring order).
• Run input names are shared identity: two steps wiring the same name receive the same caller value; different names mean separate values. Name inputs after what they are ("photo", "clip", "brief"), never a different type than the input they feed.
• Options: {"value": "<canonical string>"} fixes an option; {"ask": true, "default": "...", "note": "..."} opens it to runners, who pass it as step_options[step_id][key] at run time. Only option keys the model lists exist; get_model shows them with choices, ranges and what each does to the price.
• input_meta gives run inputs a label, help text and (text inputs only) a fixed list of choices, keyed by input name.
• deliverables names what a run gives: a list of {"name", "step_id", "output"} promoting step outputs to results by name (e.g. hero → step "page" output "web"); runs return them under deliverables, the spec lists them, and screens show them first. Set them on every pipeline whose result is more than its last step's output.
• Two output kinds exist only as step outputs, never as uploads: web (one self-contained HTML page: its url renders it in a sandbox, its download_url is the file) and archive (a zip, download only). tool-web-page makes both from a template baked into its template option — placeholders {{text}}, {{image}}, {{video}}, {{audio}}, {{document}} and {{video.mime}} and the like, nothing executable — so a pipeline can hand over a piece of a website, not just a clip.
• Keep pipelines lean — no steps the goal does not need — and price with get_pipeline_spec (total_cost_usd) before running.

Prefer not to wire by hand? POST /v1/pipelines/draft with {"brief": "..."} asks slai's builder to compose a pipeline from plain language. It answers 202 with a pipeline in status drafting; GET /v1/pipelines/{id}?wait=60 holds until it is ready (or draft_failed, with draft_error). Drafts may spend a test_budget on real test generations; what they do not spend is refunded.

Making a pipeline together with a person, stage by stage? Keep the record as a build: POST /v1/builds opens one, journal entries go to POST /v1/builds/{id}/entries, and POST /v1/builds/{id}/finalize closes it with the finished pipeline's id. Over MCP the same steps are start_build, log_build and finalize_build, and the build_pipeline prompt carries the contract.

Every input and output is a typed value. Text travels inline; binary data never does:

{"type": "text", "text": "hello"}
{"type": "image", "file_id": "<id from POST /v1/files>"}

Upload first (images, audio, video, PDF and DOCX; 25 MB, or 200 MB for video), then use the returned id:

curl -X POST https://slai-api.flybywire.se/v1/files \
  -H "Authorization: Bearer slai_your_key_here" \
  -F "file=@photo.jpg"

For large files, or from a machine that should not stream through the API: POST /v1/files/uploads with the file's name and size answers with a file id and a presigned PUT url, the bytes go straight to storage, and POST /v1/files/{id}/finish makes the file ready.

Everything a key can reach. Pagination is ?limit=&offset=; ids are UUIDs.

Key-authed requests are budgeted per key at 120 per minute with a burst of 60; a run that exceeds the account's balance is refused with 402 before anything starts. Error bodies are {"error": "…", "details": "…"} (a 402 adds topup_url).