API Reference Overview

This reference documents the public Runtype API. Use it to manage core resources such as Flows, Agents, Tools, Records, Products, API keys, model configs, and secrets.

Base URL

https://api.runtype.com/v1

Authentication

All API requests require an API key:

1Authorization: Bearer ***

See Authentication for details.

Endpoints by category

Core resources

CategoryDescriptionKey endpoints
FlowsMulti-step AI workflowsGET /flows, POST /flows
AgentsTool-using AI agentsGET /agents, POST /agents
RecordsStructured data that agents and flows can useGET /records, POST /records
ProductsDeployable containers for capabilities and surfacesPOST /products

Tools and integrations

CategoryDescriptionKey endpoints
ToolsCustom and built-in toolsGET /tools, POST /tools
SecretsManaged secret metadata and intake flowsGET /secrets, POST /secrets
Model ConfigsModel provider configurationGET /model-configs, POST /model-configs

Access and product delivery

CategoryDescriptionKey endpoints
Client TokensBrowser/client access tokensGET /client-tokens, POST /client-tokens
Client RuntimeBrowser session execution from a client tokenPOST /client/init, POST /client/chat, POST /client/resume, POST /client/feedback
ConversationsConversation state and messagesGET /conversations, POST /conversations

Common patterns

Pagination

List endpoints support cursor-based pagination:

$GET /v1/records?limit=50&cursor=rec_abc123

Response includes pagination metadata:

1{
2 "data": [],
3 "pagination": {
4 "nextCursor": "rec_xyz789",
5 "hasMore": true,
6 "limit": 50
7 }
8}

Error handling

Errors use standard HTTP status codes and include a JSON error body.

Status codeDescription
400Bad Request — invalid parameters
401Unauthorized — invalid API key
403Forbidden — insufficient permissions
404Not Found — resource does not exist
429Too Many Requests — rate limit exceeded
500Internal Server Error

Validation errors (400)

When a request fails schema validation, the body includes a details array. Each item carries a stable, machine-readable code so you can branch on the failure type without string-matching the message:

1{
2 "error": "Validation error",
3 "details": [
4 {
5 "code": "MISSING_REQUIRED_FIELD",
6 "message": "Invalid input: expected string, received undefined",
7 "path": "name"
8 },
9 {
10 "code": "INVALID_ENUM",
11 "message": "Invalid option",
12 "path": "kind",
13 "suggestion": "Expected one of: a, b."
14 }
15 ]
16}
FieldDescription
codeStable code: MISSING_REQUIRED_FIELD, INVALID_TYPE, INVALID_ENUM, OUT_OF_RANGE, INVALID_FORMAT, UNRECOGNIZED_KEYS, INVALID_UNION, CUSTOM_VALIDATION, or VALIDATION_ERROR
messageHuman-readable description of the problem
pathDotted path to the offending field (empty string for the request root)
suggestionOptional actionable hint, such as the allowed values or accepted range

OpenAPI specification

Download the full OpenAPI spec:

Import it into your API client or code-generation tool for interactive exploration. The official TypeScript SDK derives its core response and streaming types from this same committed spec, and the Python SDK exposes a Fern-generated low-level RuntypeApi through RuntypeClient.api. If a field is not present in the OpenAPI contract, do not depend on it in SDK code.