Get Workspace State
const url = 'https://aura-api-eu.strangeworks.com/api/v1/projects/example/workspace';const options = {method: 'GET', headers: {Authorization: 'Bearer <token>'}};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request GET \ --url https://aura-api-eu.strangeworks.com/api/v1/projects/example/workspace \ --header 'Authorization: Bearer <token>'Report what the workspace is on, and whether a checkout is rewriting it.
The one level-triggered read of the checkout guard: checkout_in_flight
comes from the lock a running checkout holds, not from an event, so a caller
that missed a broadcast — its own tab backgrounded mid-request, another tab,
a script — can ask instead of inferring. Read-only, so read access is enough.
Authorizations
Section titled “Authorizations”Parameters
Section titled “Parameters”Path Parameters
Section titled “Path Parameters”Responses
Section titled “Responses”Successful Response
What the workspace is on, and whether a checkout is rewriting it right now.
checkout_in_flight is read from the checkout lock itself, so it is a level
a caller can poll rather than an event it has to have received: a client that
missed the response to its own checkout, or never heard about someone else’s,
reads the true answer here.
A deployment basis carries no id — a deployment is mutable and latest-only, so
there is no stable ancestor to name, which is the same reason
parent_snapshot_id is NULL for a snapshot frozen off one. The project’s
origin_deployment_handle is frozen provenance, not the live basis, so it is
deliberately not reported here.
object
Example
{ "basis_kind": "snapshot"}Validation Error
object
object
object
Examplegenerated
{ "detail": [ { "ctx": {}, "input": "example", "loc": [ "example" ], "msg": "example", "type": "example" } ]}