Skip to content
SwiftTune
Browse docs

Quickstart

Create a tenant API key, compose a two-block flow, deploy it and call the live URL — the whole loop, from the terminal.

Create an API key

Everything after this step authenticates with a tenant API key rather than your browser session, which is what lets a script or a CI job run it unattended. Issuing one is owner-or-admin work and still uses the access token your session already holds — an API key cannot create another API key.

bash
curl -X POST https://api.swifttune.ai/api/v1/tenants/TENANT_ID/api-keys \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "quickstart"}'

The response carries the token in data.token, once. Only its hash is kept, so a key that scrolls off your terminal cannot be recovered — issue a new one and revoke the old.

bash
export SWIFTTUNE_API_KEY="the token from the response above"

Compose a flow

A flow starts empty. Creating one reserves the name; the graph itself is saved as its first version, which is what a deploy actually publishes.

bash
curl -X POST https://api.swifttune.ai/api/v1/flows \
  -H "X-API-Key: $SWIFTTUNE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "quickstart-flow"}'

Save the data.id from the response as FLOW_ID. The graph below wires an HTTP trigger straight into Workers AI — the smallest flow that answers a request with a model completion.

bash
curl -X POST https://api.swifttune.ai/api/v1/flows/FLOW_ID/versions \
  -H "X-API-Key: $SWIFTTUNE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "graph": {
      "nodes": [
        { "id": "trigger", "type": "http_trigger" },
        {
          "id": "model",
          "type": "workers_ai",
          "config": { "model": "@cf/meta/llama-3.1-8b-instruct" }
        }
      ],
      "edges": [
        { "source": "trigger", "sourcePort": "out", "target": "model", "targetPort": "in" }
      ]
    }
  }'

A graph with an unknown block, a cycle or two incompatible ports is rejected here with 422 ERR_UNPROCESSABLE — the same check the composer canvas runs before it lets you save.

Deploy it

Publishing is asynchronous: the request returns a deployment identifier immediately, and the Worker is built and uploaded behind it. Save data.id from the version response above as VERSION_ID.

bash
curl -X POST https://api.swifttune.ai/api/v1/flows/FLOW_ID/deploy \
  -H "X-API-Key: $SWIFTTUNE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"flowVersionId": "VERSION_ID"}'

Poll the deployment until its status leaves pending. A completed deployment carries the worker_url a request actually lands on.

bash
curl "https://api.swifttune.ai/api/v1/deployments?flowId=FLOW_ID" \
  -H "X-API-Key: $SWIFTTUNE_API_KEY"

Call it

The deployed flow answers on its own Worker, outside the /api/v1 namespace this guide has used so far — there is no platform key on this call, because the URL is the flow’s, not SwiftTune’s.

bash
curl -X POST "$WORKER_URL" \
  -H "Content-Type: application/json" \
  -d '{"prompt": "Summarise the SwiftTune quickstart in one sentence."}'

From here, block basics covers the rest of the catalogue and API and CLI covers authentication, errors and rate limits in full.