Skip to content

Build for durable Work.Requests are temporary.

Use Indwel’s published APIs and schemas to create and advance durable Work, submit governed operations, inspect authoritative state and Receipts, and resume the same undertaking across retries, people, systems, and time.

Make one governed request.

Start from durable Work and the application contract that defines the operation. The Release Readiness reference application creates cases, run plans, and runs through the Platform API; the route below is part of that admitted application path.

The installed application’s published schema defines the request body. Authentication establishes the caller. The Work’s governing authority still determines what the operation may actually do.

Release Readiness · cURLPlatform API
curl -X POST \
  "https://api.indwel.ai/v1/organizations/$ORGANIZATION_ID/workspaces/$WORKSPACE_ID/cases" \
  -H "Authorization: Bearer $INDWEL_TOKEN" \
  -H "Content-Type: application/json" \
  --data-binary @case.json
A real Platform route used by the Release Readiness application. The request body follows the published schema for the installed application.

The request is not the record. Work, application state, admitted Evidence, execution state, Effects, and Receipts remain available after the HTTP response ends.

Implementation Guide ↗API Reference ↗

The request can end.The Work continues.

HTTP is a transport boundary, not a lifecycle boundary. Work can wait for Evidence, authority, a person, an external system, or time after the request that advanced it has ended.

A later request continues the same undertaking against current state. Retries should address the same intended operation rather than create another one. Cancellation changes state rather than deleting history. Events can tell a client that something changed without becoming the authoritative state themselves.

A Run, where the application uses one, is an execution record in relation to Work. It is not the Work itself, and the API does not require every interaction to pretend that it is.

API access is not institutional authority.

Those distinctions still matter when developers use the APIs: authentication identifies the caller, and API scope determines which interface that caller can reach. Neither establishes institutional authority for the consequential action being requested.

The applicable Cognitive Contract, Evidence obligations, competent decision-makers, budgets, capability grants, approvals, and current Work state still govern what may proceed. Missing authority remains an explicit result; technical capability never becomes permission by default.

Engineering semantics should protect those distinctions throughout a request’s lifecycle: stale revisions must not overwrite current state, retries must preserve operation identity, and events should prompt consumers to reread authoritative state. When the Platform cannot proceed, typed failures explain why rather than obscuring the cause.

Explore Platform →

When the domain needs an application

Use Platform API directly when an existing product or system needs to participate in governed Work. Use Business App Engine when the domain also needs a versioned application definition, installation and configuration boundary, domain state, and repeatable governed behavior around that Work.

The application can own its domain semantics without recreating Indwel’s operating plane. Evidence, authority, human participation, execution, Effects, Receipts, continuity, and Settlement remain Platform concerns.

Indwel Cloud provides a managed environment for teams building with the Platform API or Business App Engine. Access during private beta is arranged directly with Indwel.

Business App Engine documentation ↗

Contracts and tools that belong in the build

OpenAPI, AsyncAPI, JSON Schema, generated types, examples, and registries expose machine-readable boundaries alongside the operating semantics the runtime enforces. Pin the version you reviewed, validate payloads, and put the same contracts into builds and integration tests.

Start with one bounded integration. Preserve the IAM, systems of record, observability, and security controls the enterprise already operates. Add only the Work, Evidence, authority, human participation, and capabilities that integration actually requires.