Exec
Package exec is the code interpreter: run a snippet in a sandbox and move files in and out.
Package exec is the code interpreter: run a snippet in a sandbox and move files in and out.
| Base URL | https://api.hanzo.ai |
| Operations | 12 |
| Auth | Authorization: Bearer $HANZO_API_KEY |
exec
GET /v1/exec/{wildcard1}
The interpreter's own execution subpaths
Whatever the executor serves below /exec, addressed verbatim — /exec/programmatic is the one this repo names, and the rest of that tree is the executor's to define. It is deliberately ONE greedy route: enumerating the executor's subpaths here would 404 every one left out of the list, so cloud carries the whole tree rather than a guess at it.
NOTHING RUNS HERE. cloud forwards the request to the sandboxed executor byte for byte and forwards its answer back the same way — the status, the Content-Type and every field are the executor's, including fields this repo has never named and including its own 4xx. There is no os/exec anywhere in this process: the sandbox is the isolation boundary, and cloud adds only the credential check and the single public address.
AUTH is a shared SERVICE key on X-API-Key, compared in constant time — not a user JWT. The chat server calls this server-side on a user's behalf, so this surface carries no org scope and no per-user identity; separation between callers is the executor's session, not this edge's. A wrong key is 401, and a deployment with no key configured is 503 rather than open.
One registration owns this address for every method, so which methods actually answer is the executor's decision, not this edge's.
| Parameter | In | Type | Required | Description |
|---|---|---|---|---|
wildcard1 | path | string | yes |
POST /v1/exec/{wildcard1}
The interpreter's own execution subpaths
Whatever the executor serves below /exec, addressed verbatim — /exec/programmatic is the one this repo names, and the rest of that tree is the executor's to define. It is deliberately ONE greedy route: enumerating the executor's subpaths here would 404 every one left out of the list, so cloud carries the whole tree rather than a guess at it.
NOTHING RUNS HERE. cloud forwards the request to the sandboxed executor byte for byte and forwards its answer back the same way — the status, the Content-Type and every field are the executor's, including fields this repo has never named and including its own 4xx. There is no os/exec anywhere in this process: the sandbox is the isolation boundary, and cloud adds only the credential check and the single public address.
AUTH is a shared SERVICE key on X-API-Key, compared in constant time — not a user JWT. The chat server calls this server-side on a user's behalf, so this surface carries no org scope and no per-user identity; separation between callers is the executor's session, not this edge's. A wrong key is 401, and a deployment with no key configured is 503 rather than open.
One registration owns this address for every method, so which methods actually answer is the executor's decision, not this edge's.
| Parameter | In | Type | Required | Description |
|---|---|---|---|---|
wildcard1 | path | string | yes |
PUT /v1/exec/{wildcard1}
The interpreter's own execution subpaths
Whatever the executor serves below /exec, addressed verbatim — /exec/programmatic is the one this repo names, and the rest of that tree is the executor's to define. It is deliberately ONE greedy route: enumerating the executor's subpaths here would 404 every one left out of the list, so cloud carries the whole tree rather than a guess at it.
NOTHING RUNS HERE. cloud forwards the request to the sandboxed executor byte for byte and forwards its answer back the same way — the status, the Content-Type and every field are the executor's, including fields this repo has never named and including its own 4xx. There is no os/exec anywhere in this process: the sandbox is the isolation boundary, and cloud adds only the credential check and the single public address.
AUTH is a shared SERVICE key on X-API-Key, compared in constant time — not a user JWT. The chat server calls this server-side on a user's behalf, so this surface carries no org scope and no per-user identity; separation between callers is the executor's session, not this edge's. A wrong key is 401, and a deployment with no key configured is 503 rather than open.
One registration owns this address for every method, so which methods actually answer is the executor's decision, not this edge's.
| Parameter | In | Type | Required | Description |
|---|---|---|---|---|
wildcard1 | path | string | yes |
PATCH /v1/exec/{wildcard1}
The interpreter's own execution subpaths
Whatever the executor serves below /exec, addressed verbatim — /exec/programmatic is the one this repo names, and the rest of that tree is the executor's to define. It is deliberately ONE greedy route: enumerating the executor's subpaths here would 404 every one left out of the list, so cloud carries the whole tree rather than a guess at it.
NOTHING RUNS HERE. cloud forwards the request to the sandboxed executor byte for byte and forwards its answer back the same way — the status, the Content-Type and every field are the executor's, including fields this repo has never named and including its own 4xx. There is no os/exec anywhere in this process: the sandbox is the isolation boundary, and cloud adds only the credential check and the single public address.
AUTH is a shared SERVICE key on X-API-Key, compared in constant time — not a user JWT. The chat server calls this server-side on a user's behalf, so this surface carries no org scope and no per-user identity; separation between callers is the executor's session, not this edge's. A wrong key is 401, and a deployment with no key configured is 503 rather than open.
One registration owns this address for every method, so which methods actually answer is the executor's decision, not this edge's.
| Parameter | In | Type | Required | Description |
|---|---|---|---|---|
wildcard1 | path | string | yes |
DELETE /v1/exec/{wildcard1}
The interpreter's own execution subpaths
Whatever the executor serves below /exec, addressed verbatim — /exec/programmatic is the one this repo names, and the rest of that tree is the executor's to define. It is deliberately ONE greedy route: enumerating the executor's subpaths here would 404 every one left out of the list, so cloud carries the whole tree rather than a guess at it.
NOTHING RUNS HERE. cloud forwards the request to the sandboxed executor byte for byte and forwards its answer back the same way — the status, the Content-Type and every field are the executor's, including fields this repo has never named and including its own 4xx. There is no os/exec anywhere in this process: the sandbox is the isolation boundary, and cloud adds only the credential check and the single public address.
AUTH is a shared SERVICE key on X-API-Key, compared in constant time — not a user JWT. The chat server calls this server-side on a user's behalf, so this surface carries no org scope and no per-user identity; separation between callers is the executor's session, not this edge's. A wrong key is 401, and a deployment with no key configured is 503 rather than open.
One registration owns this address for every method, so which methods actually answer is the executor's decision, not this edge's.
| Parameter | In | Type | Required | Description |
|---|---|---|---|---|
wildcard1 | path | string | yes |
OPTIONS /v1/exec/{wildcard1}
The interpreter's own execution subpaths
Whatever the executor serves below /exec, addressed verbatim — /exec/programmatic is the one this repo names, and the rest of that tree is the executor's to define. It is deliberately ONE greedy route: enumerating the executor's subpaths here would 404 every one left out of the list, so cloud carries the whole tree rather than a guess at it.
NOTHING RUNS HERE. cloud forwards the request to the sandboxed executor byte for byte and forwards its answer back the same way — the status, the Content-Type and every field are the executor's, including fields this repo has never named and including its own 4xx. There is no os/exec anywhere in this process: the sandbox is the isolation boundary, and cloud adds only the credential check and the single public address.
AUTH is a shared SERVICE key on X-API-Key, compared in constant time — not a user JWT. The chat server calls this server-side on a user's behalf, so this surface carries no org scope and no per-user identity; separation between callers is the executor's session, not this edge's. A wrong key is 401, and a deployment with no key configured is 503 rather than open.
One registration owns this address for every method, so which methods actually answer is the executor's decision, not this edge's.
| Parameter | In | Type | Required | Description |
|---|---|---|---|---|
wildcard1 | path | string | yes |
GET /v1/exec
Run a code snippet in a sandboxed interpreter
The code-interpreter entry point: a snippet with its language, plus any files already uploaded to the session, runs in an isolated executor and comes back as the session id, stdout, stderr and the files the run produced. This is what a chat agent's code tool calls.
NOTHING RUNS HERE. cloud forwards the request to the sandboxed executor byte for byte and forwards its answer back the same way — the status, the Content-Type and every field are the executor's, including fields this repo has never named and including its own 4xx. There is no os/exec anywhere in this process: the sandbox is the isolation boundary, and cloud adds only the credential check and the single public address.
AUTH is a shared SERVICE key on X-API-Key, compared in constant time — not a user JWT. The chat server calls this server-side on a user's behalf, so this surface carries no org scope and no per-user identity; separation between callers is the executor's session, not this edge's. A wrong key is 401, and a deployment with no key configured is 503 rather than open.
One registration owns this address for every method, so which methods actually answer is the executor's decision, not this edge's.
POST /v1/exec
Run a code snippet in a sandboxed interpreter
The code-interpreter entry point: a snippet with its language, plus any files already uploaded to the session, runs in an isolated executor and comes back as the session id, stdout, stderr and the files the run produced. This is what a chat agent's code tool calls.
NOTHING RUNS HERE. cloud forwards the request to the sandboxed executor byte for byte and forwards its answer back the same way — the status, the Content-Type and every field are the executor's, including fields this repo has never named and including its own 4xx. There is no os/exec anywhere in this process: the sandbox is the isolation boundary, and cloud adds only the credential check and the single public address.
AUTH is a shared SERVICE key on X-API-Key, compared in constant time — not a user JWT. The chat server calls this server-side on a user's behalf, so this surface carries no org scope and no per-user identity; separation between callers is the executor's session, not this edge's. A wrong key is 401, and a deployment with no key configured is 503 rather than open.
One registration owns this address for every method, so which methods actually answer is the executor's decision, not this edge's.
PUT /v1/exec
Run a code snippet in a sandboxed interpreter
The code-interpreter entry point: a snippet with its language, plus any files already uploaded to the session, runs in an isolated executor and comes back as the session id, stdout, stderr and the files the run produced. This is what a chat agent's code tool calls.
NOTHING RUNS HERE. cloud forwards the request to the sandboxed executor byte for byte and forwards its answer back the same way — the status, the Content-Type and every field are the executor's, including fields this repo has never named and including its own 4xx. There is no os/exec anywhere in this process: the sandbox is the isolation boundary, and cloud adds only the credential check and the single public address.
AUTH is a shared SERVICE key on X-API-Key, compared in constant time — not a user JWT. The chat server calls this server-side on a user's behalf, so this surface carries no org scope and no per-user identity; separation between callers is the executor's session, not this edge's. A wrong key is 401, and a deployment with no key configured is 503 rather than open.
One registration owns this address for every method, so which methods actually answer is the executor's decision, not this edge's.
PATCH /v1/exec
Run a code snippet in a sandboxed interpreter
The code-interpreter entry point: a snippet with its language, plus any files already uploaded to the session, runs in an isolated executor and comes back as the session id, stdout, stderr and the files the run produced. This is what a chat agent's code tool calls.
NOTHING RUNS HERE. cloud forwards the request to the sandboxed executor byte for byte and forwards its answer back the same way — the status, the Content-Type and every field are the executor's, including fields this repo has never named and including its own 4xx. There is no os/exec anywhere in this process: the sandbox is the isolation boundary, and cloud adds only the credential check and the single public address.
AUTH is a shared SERVICE key on X-API-Key, compared in constant time — not a user JWT. The chat server calls this server-side on a user's behalf, so this surface carries no org scope and no per-user identity; separation between callers is the executor's session, not this edge's. A wrong key is 401, and a deployment with no key configured is 503 rather than open.
One registration owns this address for every method, so which methods actually answer is the executor's decision, not this edge's.
DELETE /v1/exec
Run a code snippet in a sandboxed interpreter
The code-interpreter entry point: a snippet with its language, plus any files already uploaded to the session, runs in an isolated executor and comes back as the session id, stdout, stderr and the files the run produced. This is what a chat agent's code tool calls.
NOTHING RUNS HERE. cloud forwards the request to the sandboxed executor byte for byte and forwards its answer back the same way — the status, the Content-Type and every field are the executor's, including fields this repo has never named and including its own 4xx. There is no os/exec anywhere in this process: the sandbox is the isolation boundary, and cloud adds only the credential check and the single public address.
AUTH is a shared SERVICE key on X-API-Key, compared in constant time — not a user JWT. The chat server calls this server-side on a user's behalf, so this surface carries no org scope and no per-user identity; separation between callers is the executor's session, not this edge's. A wrong key is 401, and a deployment with no key configured is 503 rather than open.
One registration owns this address for every method, so which methods actually answer is the executor's decision, not this edge's.
OPTIONS /v1/exec
Run a code snippet in a sandboxed interpreter
The code-interpreter entry point: a snippet with its language, plus any files already uploaded to the session, runs in an isolated executor and comes back as the session id, stdout, stderr and the files the run produced. This is what a chat agent's code tool calls.
NOTHING RUNS HERE. cloud forwards the request to the sandboxed executor byte for byte and forwards its answer back the same way — the status, the Content-Type and every field are the executor's, including fields this repo has never named and including its own 4xx. There is no os/exec anywhere in this process: the sandbox is the isolation boundary, and cloud adds only the credential check and the single public address.
AUTH is a shared SERVICE key on X-API-Key, compared in constant time — not a user JWT. The chat server calls this server-side on a user's behalf, so this surface carries no org scope and no per-user identity; separation between callers is the executor's session, not this edge's. A wrong key is 401, and a deployment with no key configured is 503 rather than open.
One registration owns this address for every method, so which methods actually answer is the executor's decision, not this edge's.
How is this guide?