Orchestrator API

The Orchestrator API is the HTTP / OpenAPI surface your backend integrates against. It drives the whole lifecycle — registering policies, accepting signed intents, accepting agent proposals, and reporting verified outcomes.

This page is the narrative; the generated, always-current endpoint reference lives at Orchestrator API reference.

The lifecycle, mapped to endpoints

1. Register the policy. POST /templates compiles, validates, and stores a policy, returning a content-addressed template_id (base58 SHA-256). Use POST /templates/validate to check a draft without storing, and GET / DELETE /templates/{template_id} to read or remove one.

2. Submit the user-signed intent. POST /intents accepts a signed intent that references a template_id. The signature is verified and the referenced policy must already exist. The intent_id is a caller-supplied UUID. GET /intents/{intent_id} reads it back.

3. Submit the agent’s proposal. POST /intents/{intent_id}/proposal submits the concrete proposed action. This triggers evidence extraction and proof generation.

4. Receive the outcome. Subscribe to GET /events (SSE) for the verdict — success or failure (with evidence and any failed constraints).

Outcomes are asynchronous

Subscribe to /events

The write endpoints (POST /intents, POST /intents/{id}/proposal) return once the request is accepted — not with the verdict. The proof result arrives only on the GET /events stream. A client must subscribe to /events to learn whether a proposal passed.

Signed intents

An intent is submitted as a signed message. Supported signature schemes:

• Ed25519
• Passkey (WebAuthn / ECDSA)
• Multisig (weighted signers + threshold)

Operator config

GET /config and PUT /config expose operator-facing runtime settings. In the managed model these are handled by Delta and not part of a customer integration.

Full reference

The complete endpoint and schema reference is generated from the committed OpenAPI spec (v0.5.1):

→ Orchestrator API reference

Note

Only the orchestrator is customer-facing. The verifier, taxonomy, and evidence services are internal Delta-hosted dependencies and aren’t part of this surface.