Information
- License: Proprietary
- OpenAPI version:
3.1.0
Overview
The /v2 REST surface served by TinyConductor.
TinyConductor Orchestration API (v2-compatible) 0.1.0
Section titled “TinyConductor Orchestration API (v2-compatible) 0.1.0”Wire-compatible with the v2 orchestration REST surface described in the Compatibility guide, for the operations listed.
This document describes only what the TinyConductor engine implements today.
It is written and maintained by the TinyConductor project, and the drift test
crates/bpm-api/tests/openapi_v2_drift.rs keeps it equal to the routes the
engine registers.
Deployment modes. Every operation is served by one route layer in all
three deployment modes (Embedded, Bundled, Cluster), which differ only
in durability, latency, capacity and tenancy. Each operation carries an
x-tinyconductor-modes object with a supported or unsupported value
for each mode; unsupported appears only for the operations on the
reviewed allow-list (bpm_api_core::modes), such as the Embedded-only
virtual clock. An unsupported operation is never a silent 404. It
answers 501 with the problem type urn:bpm:error:mode-not-supported,
names the mode in mode, and gives the reason in detail.
Authorization. Each operation lists the permission it requires (an
action such as instance:create) and the kind of resource it applies to,
as x-tinyconductor-action and x-tinyconductor-resource. When the caller
lacks that permission, the answer is 403 before the engine sees the
request.
Tenancy. Each request runs in one tenant of the authenticated
principal. A principal of one tenant needs no header; a principal that
may act in several tenants selects the tenant with the x-tenant-id
header on every request (400 without it). Any tenant named in a body,
a multipart part or the header must be that tenant, or the request is
refused with 403.
Keys. Entity keys are positive signed 64-bit integers. Responses encode them as decimal strings so that JavaScript clients keep full precision.
Deferred properties. Some request properties are part of the wire
shape but have no implementation yet. The request schemas list them so
that clients which send them still parse, and each one says how it is
handled: usually a 400 when a non-default value is sent. Unknown
properties are always rejected with 400.
Authentication
Section titled “ Authentication ”bearerAuth
Section titled “bearerAuth”An OIDC access token (JWT) from the configured issuer, or a configured
static bearer token (CONDUCTOR_AUTH_CREDENTIALS_JSON). Tokens are tried in
that order.
Security scheme type: http
sessionCookie
Section titled “sessionCookie”A browser session set by the same-origin /auth/* endpoints when a
person signs in. A cookie-authenticated request that changes state (anything other
than GET, HEAD or OPTIONS) must also send X-CSRF-Token. Over plain HTTP in local
development (CONDUCTOR_SESSION_INSECURE_COOKIE=1) the cookie is called hb_session.
Security scheme type: apiKey
Cookie parameter name: __Host-hb_session
csrfToken
Section titled “csrfToken”The session’s anti-CSRF token. It is required with the session cookie on POST, PUT, PATCH and DELETE.
Security scheme type: apiKey
Header parameter name: X-CSRF-Token