API conventions - CoreWeave Docs

Model references

Management request fields use:

{provider-name}/{provider-model-id}

The provider name is lowercase and identifies stored credentials. The model ID is provider-defined and may contain additional slashes or an encoded reasoning-effort query.

Asynchronous operations

202 Accepted means desired state or background work was stored successfully, not that it is already serving or complete. Poll the returned resource:

provider and routing deployment status must become applied at the current revision;
datasets become ready or failed;
relabel runs become completed, failed, or stale;
fine-tunes become deployed or failed;
evaluations expose live case counts and may complete with failed cases.

Errors

Management API errors use:

{
  "error": {
    "message": "Task 'missing' not found in entity 'your-team'",
    "type": "not_found"
  }
}

Validation failures return 400 for malformed JSON/query values or 422 for a body that does not satisfy its schema. Conflicts such as referenced-provider deletion return 409.

Pagination

Dataset entries use page-based pagination:

GET .../entries?page=1&limit=50

limit can be from 1 to 200. The response includes page, limit, total, and entries. Entry filters and evaluation sorting are JSON-encoded query parameters. URL-encode the serialized JSON when constructing requests.

Create and replace behavior

PUT /providers/{name} creates or rotates a provider.
PUT /tasks/{alias} creates a task and returns conflict if it exists.
routing PUT replaces all targets for that version.
Automation PUT creates or replaces the configuration only while replacement is safe; active later-stage runs reject it.
Dataset, fine-tune, and evaluation POST requests create new resources and may consume compute.

Use client-side request IDs and your own orchestration state when retrying non-idempotent create calls after an ambiguous network failure.

API: Safe request handling

Use the Management OpenAPI specification as the source of truth for methods, paths, schemas, and status codes. Before sending a request, an agent should:

resolve every placeholder from user-provided or previously returned values;
show the user any request that starts paid compute or replaces routing;
treat 202 Accepted as the beginning of work and poll the documented resource;
preserve returned resource IDs instead of rediscovering resources by name;
stop on an unexpected status rather than retrying a create operation blindly.

​Model references

​Asynchronous operations

​Errors

​Pagination

​Create and replace behavior

Model references

Asynchronous operations

Errors

Pagination

Create and replace behavior