REST API · v1

API documentation

Run agents, discover available capabilities, and publish your own agents with authenticated HTTP requests.

Base URLhttps://www.runcept.com/api/v1
Production

Authentication

Pass your API key with either the x-api-key header or a Bearer authorization header.

Request header
x-api-key: runcept_sk_...
SDK-style header
Authorization: Bearer runcept_sk_...
Keep API keys on the server. Do not expose them in client-side code.

Run an agent

Send an agent slug and the input payload expected by that agent.

POST/api/v1/run
Example request
curl -X POST 'https://www.runcept.com/api/v1/run' \
  -H 'Content-Type: application/json' \
  -H 'x-api-key: runcept_sk_...' \
  -d '{
    "agent_slug": "my-agent",
    "input": {
      "prompt": "Hello world"
    }
  }'

List agents

Retrieve the agents that are currently available to run.

GET/api/v1/agents
Example request
curl 'https://www.runcept.com/api/v1/agents' \
  -H 'x-api-key: runcept_sk_...'

Connect what you already built

Import an existing API or workflow. You do not need to rewrite it as a Runcept-specific server.

  1. Paste what you have. Use a cURL request, OpenAPI 3.x URL/document, HTTPS webhook, remote MCP URL, or GPT Actions schema.
  2. Confirm credentials. Secret values go directly to encrypted Vault storage and are never kept in the browser draft.
  3. Test a real operation. Review the exact request and a bounded, redacted response preview.
  4. Shape the storefront. Choose operations, customer fields, result fields, completion mode, and per-run pricing.
  5. Submit for review. Runcept verifies the selected production contract without charging a customer.
Paste a working cURL request
curl -X POST 'https://api.example.com/v1/generate' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer YOUR_API_KEY' \
  -d '{"prompt":"Create a product launch outline"}'

OpenAPI 3.0 or 3.1

Paste JSON/YAML or provide a public HTTPS spec URL. Runcept imports JSON request/response schemas and operation IDs. Swagger 2, arbitrary callbacks, non-JSON bodies, mTLS, and cookie auth route to the generated bridge path instead of being silently misconfigured.

Minimal importable spec
openapi: 3.1.0
info:
  title: Product workflow
  version: 1.0.0
servers:
  - url: https://api.example.com
paths:
  /v1/generate:
    post:
      operationId: generateProductOutline
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required: [prompt]
              properties:
                prompt: { type: string, example: "Launch a coffee subscription" }
      responses:
        "200":
          description: Finished result

Supported connections and authentication

The import wizard only offers modes the execution runtime can enforce safely.

Directly supported

  • HTTPS JSON APIs and webhooks
  • API keys in a header or query parameter
  • Bearer and Basic authentication
  • OAuth 2 client credentials and authorization code
  • Remote Streamable HTTP MCP servers
  • Sync, durable polling, and callback completion

Use the generated bridge

  • mTLS, signed requests, or custom cryptography
  • Cookie/session authentication
  • Multipart files, binary bodies, SOAP, or GraphQL transforms
  • Local or stdio MCP servers
  • Arbitrary JavaScript transformations

Choose a tested TypeScript/Next.js, Express, or Python/FastAPI adapter. The generated coding-agent prompt includes your schemas and environment-variable names, never an entered secret value.

Runcept stores per-connection credentials in Vault. Responses only expose masked labels; raw values and Vault IDs never return to the browser.

n8n, Make, Zapier, and Pipedream

n8n setup
1. Add a Webhook node that accepts POST JSON.
2. Paste its production HTTPS URL into Runcept.
3. Map the customer fields to your webhook body.
4. For a synchronous workflow, return JSON with "Respond to Webhook".
5. For a long workflow, select Callback and use the callback_url,
   callback_token, and run_id fields Runcept injects into the request.

Remote MCP

MCP transport
Remote MCP URL
https://mcp.example.com/mcp

Runcept supports remote Streamable HTTP MCP servers.
Local stdio MCP servers cannot run from a hosted Runcept function.

Custom GPTs

Paste a GPT Actions OpenAPI schema to migrate its callable operations. GPT instructions can be converted into builder guidance, but Runcept cannot host a ChatGPT Custom GPT or copy its private knowledge files. Use a connected API or generated bridge for that logic.

Long-running work

Choose polling when your API already exposes job status, or callback when your workflow can push the result later.

Durable polling

Runcept snapshots the job ID and deadline, polls only the configured HTTPS status URL template, and settles the customer run once. Poll state survives a browser closing or a function restart.

Polling configuration
{
  "mode": "poll",
  "job_id_pointer": "/job_id",
  "status_url_template": "https://api.example.com/jobs/{job_id}",
  "status_pointer": "/status",
  "running_values": ["queued", "running"],
  "complete_values": ["complete"],
  "failed_values": ["failed"],
  "result_pointer": "/result",
  "poll_interval_seconds": 5,
  "deadline_seconds": 3600
}

Callback

The initial request receives a one-time callback token, Runcept run ID, callback URL, and deadline through fields you map in the wizard. Callback payloads are idempotent: retrying the identical result is safe; a conflicting payload is rejected.

Callback pattern
// Initial request: acknowledge quickly
return Response.json({ accepted: true }, { status: 202 })

// Later: send the final result to the injected callback_url
await fetch(callback_url, {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-Runcept-Callback-Token': callback_token
  },
  body: JSON.stringify({
    status: 'complete',
    output: { asset_url: 'https://cdn.example.com/result.mp4' }
  })
})

Agents with multiple operations

Each exposed operation can have its own input schema, output schema, completion mode, and server-resolved price.

REST
curl -X POST 'https://www.runcept.com/api/v1/run' \
  -H 'Content-Type: application/json' \
  -H 'x-api-key: runcept_sk_...' \
  -d '{
    "agent_slug": "research-suite",
    "operation": "company-research",
    "input": { "company": "Runcept" }
  }'
CLI
runcept run research-suite \
  --operation company-research \
  --input '{"company":"Runcept"}'
TypeScript SDK
const result = await runcept.run(
  'research-suite',
  { company: 'Runcept' },
  { operation: 'company-research' }
)

If an agent exposes exactly one operation, operation may be omitted. For multiple operations it is required; unknown keys fail before any balance is reserved.

Build with workflows

Compose multi-step agents visually — connect integrations, LLM steps, and branching logic without writing or reading JSON.

Node types

A workflow is an ordered sequence of steps. Nine node types cover the whole builder — the three marked branching each carry their own private branch/body, which always reconverges at the workflow's next step:

  • Integration — call an operation from a connection you've attached (an imported API, MCP server, or automation tool).
  • LLM — a prompt template with bound variables, run against a Runcept-reviewed model.
  • Code — TypeScript or Python, executed in an isolated sandbox with no network access unless you explicitly grant a domain.
  • Artifact — package a step's output as a downloadable file (JSON, Markdown, CSV, PDF, image, or video).
  • Wait — pause until a specific timestamp, for a fixed duration, or until an external callback resolves it.
  • Approval — pause for a human decision before continuing.
  • Condition (branching) — route to one of several branches based on a bound field (equals, greater/less than, contains, exists), with an optional default.
  • Parallel (branching) — run two or more branches concurrently, then join on all-succeed, minimum-successes, or collect-failures.
  • Map (branching) — run the same steps once per item in a bound array, with a concurrency and item-count limit.

Bindings

Every step's inputs are bound, never templated as a string. Three sources, addressed with an RFC 6901 JSON Pointer path:

  • workflow_input — a field from the run's own input, e.g. /url.
  • step_output — a prior step's output, referenced by that step's id.
  • map_item — inside a map node's body only: the current array item being iterated.

Code steps: sandboxing and limits

Code runs in an isolated microVM sandbox as an unprivileged user, terminated after every attempt. Network access is default-deny — a code step can reach only the domains you explicitly declare, and every domain grant is reviewed before publishing. There is no way to inject a raw credential into a code step's environment; connection credentials are only ever attached by the network layer on egress to a domain you've been granted.

Code steps can be built, configured, and saved today, but live execution is not yet enabled while the adversarial isolation test suite runs — every other node type executes normally.

Waits, callbacks, and approvals

When a run reaches a wait or approval node, it suspends — GET /api/v1/jobs/{job_id} reports it as still in progress, no balance is charged for the pause itself. Resolving it requires the one-time resume token issued when the run first suspended (delivered out of band, never re-derivable from the run or node id):

Resume a suspended run
curl -X POST 'https://www.runcept.com/api/workflows/runs/{workflow_run_id}/resume' \
  -H 'Content-Type: application/json' \
  -H 'X-Runcept-Resume-Token: <token>' \
  -d '{
    "nodeId": "approve",
    "decision": { "approved": true }
  }'

Artifacts

An artifact step's output is a reference, not the file itself: { artifactId, checksum, sizeBytes }. Exchange the id for a short-lived signed download URL:

GET/api/workflows/artifacts/{artifact_id}/download

A public artifact downloads with no authentication. A private artifact currently requires being signed in to the dashboard as the customer who ran the workflow — API-key callers cannot fetch a private artifact's signed URL yet.

Running a workflow-backed agent

Once published, a workflow-backed agent is indistinguishable from any other agent to a caller — run it and poll it exactly as described above in Run an agent. A job's status response includes a workflow field distinguishing an actively-executing run from one paused on a wait/approval node.

Cancelling a run

Cancelling an actively-executing run requests a stop at its next safe checkpoint, between steps — never mid-step, so a step already in flight always finishes with a known outcome. A queued or paused run is cancelled immediately.

POST/api/v1/jobs/{job_id}/cancel
Example request
curl -X POST 'https://www.runcept.com/api/v1/jobs/{job_id}/cancel' \
  -H 'x-api-key: runcept_sk_...'

Advanced: custom Runcept endpoint

Keep the original endpoint contract when direct import cannot express your transformation.

POST/api/v1/agents/register

Endpoint agents are verified before entering review. Runcept sends a preflight POST with the same { input, run_id } envelope used for real runs and the X-Runcept-Preflight: true header. Return successful JSON without performing billable work when that header is present. Add an example, default, or enum to every required string input so Runcept can construct the preflight request.

Accounts may submit up to 5 agents per hour and 20 per day. Accounts less than seven days old may have 5 pending submissions; established accounts may have 10.

Example request
curl -X POST 'https://www.runcept.com/api/v1/agents/register' \
  -H 'Content-Type: application/json' \
  -H 'x-api-key: runcept_sk_...' \
  -d '{
    "name": "My Agent",
    "slug": "my-agent",
    "endpoint_url": "https://your-agent.example.com/run",
    "price_usd": 0.10,
    "input_schema": {},
    "output_schema": {}
  }'