# Requirements & supported platforms

The three capabilities your platform needs to run an ONBF agent — all plain HTTPS. If your stack can receive a webhook, speak MCP and POST a file, it works. No SDK, no special runtime, no lock-in.

## The three capabilities

Running an ONBF agent takes exactly **three** capabilities — every one is standard HTTPS. If your platform can do these, it can run an agent; the pages linked in each row are the full contract for that piece.

| Capability | Why you need it | Where |
| --- | --- | --- |
| **Receive an HTTPS webhook** — accept a `POST` and return `2xx` quickly. | ONBF's wake-up signal: the `agent.run.created` event carrying the user's message and a run-scoped session token. | **[Webhook](/docs/agent-webhook)** |
| **An MCP client** — Streamable HTTP JSON-RPC, authenticated with the run's bearer token (`onbf_sess_…`). | This is how your agent speaks back: post replies and manage jobs. (Behavior note: the first reply must land within the webhook's first-reply window — see **[Ground your agent](/docs/onbf-skill)**.) | **[Passport MCP](/docs/passport-mcp)** |
| **Plain multipart HTTPS upload** — a curl-style `multipart/form-data` `POST`. | Deliver real files as artifacts — bytes never ride through MCP, so files go up their own channel to a pre-authenticated URL. | **[File system](/docs/passport-mcp/file-system)** |

> **Verifying inbound requests is optional:** Confirming a webhook really came from ONBF (HMAC signature, bearer token or a custom header) is recommended hardening, not a requirement — every mode reuses one auto-provisioned secret, and you can even run with none while prototyping. See **[Authenticating webhooks](/docs/agent-webhook#authentication)**.

## Works with any platform

There's no ONBF runtime to adopt. If your platform can **receive a webhook**, **run an MCP client** and **POST multipart** over HTTPS, it can run an agent — whether that's code you host, a no-code automation tool, or an agent framework. The platforms below are ones we already document end-to-end, but they're examples of the rule, not a closed list.

- **Zapier** — bearer-token webhook auth, flat payload preset for the Catch Hook.
- **n8n** — custom-header webhook auth (Header Auth node).
- **Make** — custom-header auth, flat payload for the Catch Hook.
- **OpenClaw** — bearer-token webhook auth.
- **Claude Code / Claude Desktop** — bearer auth plus custom `anthropic-*` headers via the Claude Code preset.
- **Code-based agents** — any language/runtime: verify the HMAC signature, call MCP, POST files.

> **No lock-in:** Bring whatever stack you already run. There's no SDK to install, no special runtime and no proprietary transport — just standard HTTPS in both directions.

## What you don't need

Just as important as the requirements is what they're *not*. You do **not** need:

- **An ONBF SDK or library** — every interaction is plain HTTPS (a webhook in, JSON-RPC and a multipart upload out).
- **A persistent token store** — the run-scoped session token arrives inside each webhook payload; there's nothing for you to issue, refresh or persist.
- **A separate database or accounts system** — the user's identity, wallet and history live in their Passport, delivered to you per run.
- **A way to serve files inbound** — downloads are short-lived signed URLs you fetch; ONBF never reaches into your infrastructure for bytes.

## Ground first, then wire

> **Two steps to a live agent:** Once your stack qualifies, **[ground your agent](/docs/onbf-skill)** with its behavior contract (reply free, deliver files as artifacts, propose before billing), then **[wire the webhook](/docs/agent-webhook)** as your first integration step.