Concepts

Providers, capabilities and specifications

These three resources describe what a Runtime *can* do, not what any one Runtime instance is currently doing:

• Providers (GET /api/v1/providers) are the systems a Runtime can act through — for example GitHub. Each entry's status reflects whether that provider has been used recently in this organization's audit history (connected) or not (offline); scope and last_used come from the organization's own provider record, not from a live health check against the provider itself.
• Capabilities (GET /api/v1/capabilities) are the individual operations a provider exposes — filterable by provider and free-text q. A capability's path identifies where it is defined in the capability source, not a URL.
• Specifications (GET /api/v1/specifications) are the underlying operation contracts capabilities are built from, alongside the exact Runtime version they were generated from.

Providers are generated from a selected released Runtime version; capabilities are generated independently from a separately pinned company capability registry. The two are versioned independently — a provider being listed does not imply every capability for it has shipped, and vice versa.

Fleet status

GET /api/v1/fleet reports each registered Runtime's most recently reported version, policy_version, and a derived status based on how long ago it last heartbeat:

status is derived at read time from last_seen — it is not a value a Runtime reports about itself, and there is no separate "Runtime went offline" event.

Policy and configuration

Policy and managed configuration are each independently versioned per organization. Publishing either one is append-only and produces a new signed governance generation — a single Ed25519-signed envelope covering both the current policy and current configuration together, served from GET /api/v1/sync-bundles/active. A version, once published, cannot be republished under the same identifier: publishing POST /api/v1/policies or POST /api/v1/configurations with a version that already exists returns 409, specifically so that an audit record referencing a policy version always resolves to the exact document that produced it.

Only an administrator may publish policy or configuration, or manage API keys. Every other portal route is readable by any authenticated user in the organization.

Versioning and compatibility

This API's schema version is published at the top of the generated reference on / (OpenAPI 3.x, current app-api contract version). The contract you see here is generated directly from app-api's implemented routes on every publish — it cannot describe a future or proposed endpoint as available. Any forward-looking capability mentioned in prose elsewhere on this site (for example on this page) is explicitly non-contractual until it appears as an operation in the generated reference.

Breaking changes to an operation's request or response shape are called out in the release notes for the Control Plane version that introduces them, including the minimum compatible Runtime version where applicable. There is no separate deprecation-header mechanism today — an operation is either present in the current contract or it is not.

Source, provenance and support

Every build of this site publishes /contract.json alongside the generated reference — a sha256 digest of the exact openapi.yaml this site was built from, plus the contract's version string. Compare it against your own copy of the contract to confirm you are reading the version your Runtime or integration was built against.

This site is a read-only reference with no execution surface and no request path of its own. To register a Runtime, request Enterprise access, or get help with an integration, use your organization's Enterprise portal at app.engineeringruntime.com — your Enterprise administrator can issue credentials and answer access questions from there.