Deployment

Deploying a function compiles it into an immutable version and exposes it as an authenticated HTTP endpoint.

The run API

Every deployed version answers at a stable path. The shape is POST /fn/{name}/{version}/run:

curl -X POST https://api.fn.run/fn/classify/v3/run \
  -H "Authorization: Bearer $FN_KEY" \
  -F input=@ticket.pdf

The response is your typed output under output, plus a meta block:

{
  "status": "success",
  "output": {
    "category": "billing",
    "priority": "high",
    "confidence": 0.94
  },
  "meta": {
    "version": "v3",
    "latency_ms": 142,
    "cost_usd": 0.003,
    "tokens": 1840,
    "trace_id": "run_8f3c2a1d"
  }
}

status is one of success, partial, failed, or escalated. trace_id addresses the full run — pass it to fn logs or the API to replay exactly what happened.

Authentication

Requests are authenticated with a bearer token. Create scoped API keys per environment in your dashboard, and pass them as Authorization: Bearer <key>. Keys can be restricted to specific functions.

Environments

A deploy targets a named environment — typically development, staging, and production. Each environment keeps its own version history and aliases, so shipping to staging never touches production traffic.

Aliases & rollback

Instead of calling a fixed version, route traffic through an alias:

fn pin classify stable --to v3
fn pin classify canary --to v3-rc1

Then call POST /fn/classify/stable/run. To revert, re-point the alias — no rebuild, no redeploy:

fn rollback classify --to v2

Rollback is instant because every version already exists; you are only moving a pointer.