Proxy HTTP to a running workforce deployment (agent or workflow). Non-serverless: method and headers pass through; JSON on /run or /stream may get context.platform_config merged for SDK auth-back. Serverless: no upstream URL — the platform runs the workforce for this request. Pass workforce as id, manifest UUID, or name; rev is the git branch. Response header X-Timbal-Workforce-Deployment-Type is serverless, ecs, or on-premise. WebSocket upgrades are not supported.
This route is a gateway proxy to a running workforce deployment (an agent or workflow). The platform forwards your HTTP request to the deployment; responses pass back through unchanged (aside from normal proxy behavior).Documentation Index
Fetch the complete documentation index at: https://docs.timbal.ai/llms.txt
Use this file to discover all available pages before exploring further.
| Method | Use case |
|---|---|
| GET | Read-only calls (e.g. health, metadata). |
| POST | Typical RPC-style calls (e.g. …/run). |
| PUT / PATCH | Idempotent or partial updates when your component exposes them. |
| DELETE | Deletes or teardown actions your component exposes. |
workforce — Which component to hit: numeric id, manifest UUID, or name (same identifiers you use elsewhere in the project API).path — Suffix on the deployment server after the component segment (for example run or healthcheck). Use the path your running app defines; can be empty for the deployment root.rev (query, required) — Git branch the deployment is tied to (for example main).rev, you get 404. If the deployment returns an error upstream, you may see 502.Timbal API key. Obtain your API key from the Timbal platform settings. See Authentication for more information.
Organization id
Project id
Workforce component: numeric id, manifest UUID, or name
Path on the deployment server after the component segment (for example run or healthcheck). Leave empty to call the deployment root.
Git branch name (for example main).
Response from the workforce deployment