Features
Platform API

One stable connection for every backend you run.

Your product calls a deployment on a versioned API. The workflow behind it can improve release by release while the request your code sends stays the same.

Read the API guide OpenAPI contract

curl -X POST \
  https://vendor.sh/api/v1/workflows/inbound-email/runs \
  -H "Authorization: Bearer $VENDOR_KEY" \
  -H "Idempotency-Key: ticket-48213" \
  -d '{"input": {"subject": "Charged twice"}}'

{
  "data": {
    "id": "01J8ZQ4K7T2M9V3XB0RHYWCE5F",
    "status": "pending",
    "mode": "async",
    "deployment": { "slug": "inbound-email", "environment": "production" },
    "release": { "number": 3 },
    "usage": { "cost": "0.0000", "tokens": 0, "duration_ms": null }
  }
}

event: run.started
data: {"run_id":"01J8ZQ4K7T2M9V3XB0RHYWCE5F"}

event: node.succeeded
data: {"node":"support-triage","duration_ms":520}

event: run.succeeded
data: {"status":"succeeded"}

202 Accepted · queued, and followable on the run stream

The shape of it

Several products. One request each. The work stays in one place.

Your callers

A web backend, a mobile service, an internal job

Each sends the same POST to the same deployment. Nothing about the workflow reaches your code.

A service key

abilities · deployment allowlist · expiry

The key decides what the caller may start and which deployments it may reach.

A deployment

production → release v3

The deployment points at one immutable release, and you move it forward on purpose.

What your code can rely on

Built for the retry, the timeout and the next release.

Versioned path

Everything lives under /api/v1, so a change of shape arrives as a new version.

OpenAPI 3.1 contract

Published at /openapi.json. Generate a client or read it directly.

Idempotency-Key

Send one per intent. A retried request never starts a second run.

Server-sent events

Follow each step as it runs instead of polling for the end.

202 Accepted

Long work is queued and answered at once with a run you can follow. A sync run answers 200.

Project service keys

Limited abilities, a deployment allowlist, an expiry and revocation.

Connect a backend

From a key to a handled result, in four steps.

01

Create a service key

Limit it to one project, the abilities it needs and the deployments it may call.

Settings → API keys
02

Start a run

POST to the deployment with an Idempotency-Key for each intent.

POST …/runs
03

Follow it

Read the event stream or fetch the run until its status is final.

GET /api/v1/runs/{id}
04

Handle the result

Use the structured output, and the usage record that came with it.

data.output

Send your first request against a deployment.

One POST, an Idempotency-Key, and a run you can follow to the end.