> ## Documentation Index
> Fetch the complete documentation index at: https://docs.winterr.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Follow an API operation

This guide describes operation handling in the API and SDK source. Confirm
[service availability](/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](/providers) for capacity limits and
retained resources. Inference response requests have different
[retry rules](/inference).

## 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.