Reference for evaluating integration.
These interfaces describe the coordinator as it runs today. There is no public API endpoint or signup flow. Examples are reference material, and interface details may change before launch.
Customer routes use Authorization: Bearer <api-key>. Job and usage reads are scoped to the authenticated customer. A future portal will need its own secure access flow.
Customer interfaces
What the coordinator exposes
| Method & path | Purpose | Current boundary |
|---|---|---|
POST /v1/jobs | Submit a placement policy, and optionally a workload | Requires a policy. A workload is optional and, if present, names either a container image pinned by digest or a WebAssembly module pinned by digest. Never both. See the WebAssembly surface. |
GET /v1/jobs/:id | Read job state | Includes placement availability and waiting reasons where recorded. |
GET /v1/jobs/:id/bundle | Download a signed bundle | Available after placement for 30 days from verification, longer on a retention plan. Not proof of completion. |
GET /v1/usage | Read usage totals | Recorded charges; not payment settlement. |
GET /v1/usage/entries | Read individual usage entries | Customer-scoped ledger entries. |
GET /v1/jobs | List jobs | Your own jobs, newest first, 50 per page. Pass next_before back as ?before= for the next page. |
DELETE /v1/jobs/:id | Request cancellation | Incomplete lifecycle support: queued jobs currently return 409. |
Policy-based placement
Your requirements shape the match.
A StrongBox requirement excludes a TEE-only result. If no qualifying slot is available, the broker keeps the job queued with waiting reasons rather than weakening the policy.
Requirements recognized as impossible across all supported roots are rejected at submission. This differs from temporarily unavailable hardware.
Download this policy example →{
"policy": {
"name": "strongbox-verified-boot",
"rules": [
{
"claim": "boot.state",
"op": "equals",
"value": "verified"
},
{
"claim": "boot.locked",
"op": "equals",
"value": "true"
},
{
"claim": "security.level",
"op": "equals",
"value": "strongbox"
}
]
}
}Invalid request
A missing policy, malformed requirement, or unknown JSON field fails rather than being silently ignored.
Queued
A valid placement request is accepted into the queue. This does not mean execution has started.
Incompatible policy
The broker identifies a requirement that no currently supported root can provide.
Workload delivery
The WebAssembly surface
A job may name a WebAssembly module instead of a container image. The module is fetched by the machine that will run it, checked against the digest you gave, and executed in an interpreter that has been granted nothing at all.
| Field | Meaning |
|---|---|
module | An HTTPS URL. Credentials in the URL are refused, and so is a host that resolves to a private, loopback or link-local address, because the fetch is made by the operator machine from inside the operator network. |
module_sha256 | Required. Lowercase hex, 64 characters, no prefix. The node refuses anything that is not these exact bytes, so the URL is only a delivery route and the receipt names the artifact. |
func | Required. The exported function to call. We do not guess _start. |
func_args | Up to sixteen integers. This is the whole input interface today. |
timeout_seconds | Optional. Thirty seconds by default, three hundred at most. |
args, env | Refused on a module. A sealed module has no argv and no environment to read them from, so accepting them would mean dropping your configuration silently. |
The module is granted nothing. No filesystem, no network, no environment, no arguments, no host clock and no host randomness. Any import at all is refused before the engine loads the module, and the refusal names the import. That is what makes a run on this surface repeatable by somebody else, which is the thing we are selling.
So a module compiled against a standard library will be refused, and you should know that before you compile. Anything built with Go’s GOOS=wasip1, or against the C or Rust standard libraries, imports a clock, a random source and a write function. Those are exactly the imports that make a run unrepeatable, which is why they are not granted. A module that runs here imports nothing: freestanding Rust or C, hand written WebAssembly, or a toolchain told to target no system interface.
Memory and a table are allowed, bounded rather than forbidden, because real compiled code has both: sixteen megabytes of memory and four thousand table entries. The engine implements WebAssembly 2.0. Garbage collection is not supported, which excludes Kotlin, Dart and Java through WasmGC.
A test module, so you can check your own integration rather than take our word for it. Forty one bytes, no imports, one export named sum taking two 64 bit integers and returning their sum:
{
"policy": { "name": "any-attested-device", "rules": [] },
"spec": {
"module": "https://svnkg.com/wasm/sum-i64.wasm",
"module_sha256": "2448fdf68d5bfed2b383802ef03319436f6b5fb991753bb809b83636c691e6a2",
"func": "sum",
"func_args": [3, 4],
"timeout_seconds": 30
}
}Its source is three lines of WebAssembly text at sum-i64.wat. Fetch the module, hash it yourself, and compare it with the digest above before you trust anything else on this page.
What has and has not happened. This surface is built and covered by tests on both the coordinator and the node. No customer module has run on it yet, and until one has we will not describe it as proven. Container execution is a separate matter: container jobs have run on rented and borrowed hardware, but the machines we own have hardware virtualisation disabled, so none has run on ours.
The remaining integration work
Public deployment, HTTPS, customer onboarding, ownership-bound operator access and payment settlement are still needed for a public compute service. Workload delivery and execution are no longer on that list for WebAssembly: a module can be submitted, fetched, verified against its digest and run. It is on the list for containers, which need a runtime the machines we own cannot provide.
See development status →