async: true: the API answers at once with the run and you pollGET /v2/chat/completions/{id}until it finishes.webhook_url: the run is asynchronous automatically, and Tela POSTs the result to your URL when it finishes.
GET /v1/completion-run.
The
webhook_url of a completion reports that one run. It is not the same as Workstation Events, which are subscriptions configured on an App and fire for every task of that App.The run object
Asynchronous calls answer with the run instead of achat.completion. The same object is returned by polling and posted to your webhook. Its status moves from created to running, then to succeeded or failed.
What a run with
status: "failed" carries about the failure is not documented here. Treat failed as terminal and check the run in the Canvas Usage.Using the async flag
Addasync: true to the body. The response is the run with status: "created".
Polling the result
CallGET /v2/chat/completions/{id} with the run ID until status is succeeded or failed, then read output_content.content. The examples below start a run and poll it in one script.
Using a webhook URL
Pass awebhook_url and the run becomes asynchronous without the async flag. The immediate response is the run with status: "created"; when the run finishes, Tela sends a POST request to your URL.
The callback
Your endpoint receives aPOST with:
- Headers:
Content-Type: application/jsonandx-completion-run-id, the ID of the run. Use it to match the callback with the run you created, since it is the sameidthe creation response returned. - Body: the run object with its final
status(succeededorfailed) and, on success, the answer inoutput_content.contentandraw_output.
2xx, then process it. Whether a delivery is retried when your endpoint fails is not documented here, so if you need a guarantee, also poll GET /v2/chat/completions/{id} for runs that have not reported back after a while.
Listing past runs
Every completion, synchronous or not, is stored as a completion run.GET /v1/completion-run returns the runs of your Workspace, most recently updated first, so you can audit what ran, reconcile a batch or find a run whose callback you missed.
cURL
data array and a meta object with totalCount, limit, offset, currentPage, totalPages and links (first, last, next, previous). Each run has the same information as the run object above, with two differences: the keys are camelCase (inputContent, rawInput, promptVersionId) and it adds tags, creditsUsed, promptId and a metadata snapshot of the version that ran (modelConfigurations, variablesDefinitions and, when the request used an environment, requestedEnvironmentName).
Response
member role or higher; Workspace API keys satisfy this. When you filter by promptId, promptVersionId or promptApplicationId, the resource must be accessible to your key, otherwise the call returns 404.
To read one run by ID at any time, use GET /v2/chat/completions/{id}, as in Polling the result. Full parameter and schema details are in the API reference: Run Canvas, Retrieve Canvas Run and List completion runs.