Skip to main content
This guide describes operation handling in the API and SDK source. Confirm service availability for your project before you create a resource.

​
Resource and operation

An accepted asynchronous create request returns a resource and an operation. Save both identifiers. The resource describes the requested object. The operation tracks the requested change. Poll GET /v1/operations/{id} to follow that change. A successful operation is not proof that a submitted job has finished its work; inspect the job state and output separately. The operation states are pending, running, succeeded, failed, and cancelled. A response that accepts a request is not a success result. Continue until a terminal state or your local timeout. Inspect the operation error when a change fails.

​
SDK behavior

The TypeScript SDK has client.workflows.jobs.runAndWait(...). The Python SDK has client.workflows.jobs.run_and_wait(...). These helpers create the job and wait for its operation. They return the original create response resource together with the completed operation. They do not refresh that resource. Get the resource again to read its current state. A failed or cancelled operation raises an error. A local wait timeout also raises an error; it does not confirm that the server cancelled the work. Both clients accept an API key and a base URL. Set these for the environment you intend to use. Keep API keys out of source files and logs. The strict validation option checks responses against the SDK contract. For resource creates that support idempotency, use an idempotency key for a request that you may need to retry. Retain the same key and request content for that logical request. Use a new key for a new request. Do not treat an interrupted connection as proof that creation failed.

​
Wait for an existing operation

Use client.workflows.operations.wait(operationId) in TypeScript or client.workflows.operations.wait(operation_id) in Python. Both poll at a default interval of one second and use a default wait timeout of 30 minutes. TypeScript uses timeoutMs and pollIntervalMs; Python uses wait_timeout and poll_interval, in seconds. A request can take additional time to finish. The public field is state. Read error for a failed operation and result when present. Keep the resource ID, operation ID, and API request ID for support.

​
Cancel and clean up

Stopping a local wait or closing a client does not cancel server work. The server rejects operation cancellation for resource create and lifecycle operations with a conflict. Use the resource’s supported stop, cancel, or delete action instead. An action must be available for that resource and project. Follow the returned operation and get the resource again. An accepted delete is not proof that deletion is complete. A failed create or an interrupted request can still need cleanup. Do not submit a new create with a new key while the first request has an unknown result. Check the existing resource and operation; contact support if you cannot establish the result. See provider and cleanup expectations for capacity limits and retained resources. Inference response requests have different retry rules.

​
Verification limits

The SDK package checks execute create-and-wait examples against local API fixtures. These checks verify package installation and Operation handling. They do not allocate a GPU or prove that a provider ran a workload. Public package installation, live provider access, and production execution need separate release and environment checks.