Shared SaaS projects

Name: Mockarty
Author: Mockarty

Shared SaaS stores project data for one explicit Cloud Space and makes that data available to authorized Cloud and Desktop users. It is separate from an isolated Mockarty instance and from projects that stay only on a local Desktop.

Check availability

Open Runtime in the Cloud cabinet. Shared projects are usable only when the Mockarty in the cloud card shows Available. The same card has an Open Mockarty button.

On the Overview tab, the account status line says whether everything is in order. Expand Access details below it to see where your Mockarty runs and where project or run data is stored. While a check is running, access is refused, or the cloud is reconnecting, Cloud does not silently redirect the action to Local, Company, or another environment.

Work with projects in the cabinet

Select the required Space.
Open Runtime.
Expand Shared projects (for Desktop and API sync) and enter a name and a valid JSON body.
Create the project. Use Edit to save the next revision.

Updates and deletes use the displayed revision. If another member changed the project first, refresh the list and repeat the edit against the current revision.

CLI

Configure the CLI with the Cloud URL and an API token that has shared-projects:read or shared-projects:write. Keep the project body in a JSON file.

mockarty-cli cloud-shared-projects list --space 11111111-1111-4111-8111-111111111111

mockarty-cli cloud-shared-projects create \
  --space 11111111-1111-4111-8111-111111111111 \
  --request-id 33333333-3333-4333-8333-333333333333 \
  --name acceptance \
  --body-file ./project.json

mockarty-cli cloud-shared-projects update 22222222-2222-4222-8222-222222222222 \
  --space 11111111-1111-4111-8111-111111111111 \
  --name acceptance-v2 \
  --body-file ./project-v2.json \
  --revision 1

List, get, create, update, and delete are available. --space is always required; the CLI never guesses a Space from another profile.

--request-id is optional and must be a UUID. For create, save the value until you receive a definite response. If the connection breaks or the service returns 5xx, repeat the exact same create command with the same UUID. The service returns the first project instead of creating a duplicate. Reusing that UUID with a changed name, body, or Cloud principal returns 409. The cabinet and Desktop apply this rule automatically. Updates and deletes still rely on the displayed revision; their request ID is audit correlation, not a replay receipt.

REST API

Use the public Cloud endpoints:

GET    /api/v1/cloud/spaces/{space_id}/shared/projects
POST   /api/v1/cloud/spaces/{space_id}/shared/projects
GET    /api/v1/cloud/spaces/{space_id}/shared/projects/{project_id}
PUT    /api/v1/cloud/spaces/{space_id}/shared/projects/{project_id}
DELETE /api/v1/cloud/spaces/{space_id}/shared/projects/{project_id}?revision={revision}

Authenticate with the Cloud session or one X-API-Key/Bearer API token. Do not send two credential types in the same request. The runtime-token, sync, run-event, revision, and transfer endpoints are private and are not a supported customer API.

For a retryable create, send a canonical non-zero UUID in X-Request-ID and reuse it only for the exact same request after an ambiguous network or 5xx result. If the header is absent or is not a valid non-zero UUID, Cloud generates a new operation ID; a separate client process cannot reliably repeat it.

The service returns 404 when the authenticated account is not a member of the requested Space, 409 for a stale revision, 429 with Retry-After when Shared admission is busy, 503 with Retry-After and the code runtime_authority_reconciling for a member whose access was granted a moment ago and is still being applied (retry after the given seconds), and 503 when current runtime authority is unavailable. A foreign Space is deliberately indistinguishable from a missing one. Retrying a failed Shared request never changes its execution location.

Desktop boundary

A Desktop Cloud profile must have an explicit Space, an approved device credential, and the committed Cloud server identity. Shared requests exchange that credential for a short-lived Space-scoped runtime credential. Revoking the device or its Space membership prevents a new exchange. Local and Company profiles are separate routes and are not fallbacks for a failed Shared request.

In a Desktop build that includes Shared run, validate a Shared project as follows:

Activate the authorized Cloud profile in Settings.
Open Shared run and paste the project’s UUID.
Optionally require the project body to be a JSON object, then select Validate in Shared.
Keep the page open while the status updates. Use Cancel run to stop an active validation.

Desktop shows unavailable, revoked, conflict, and busy states explicitly. It does not move the run to Local, Company, or Managed execution. This action is a first-party Desktop feature; run lifecycle routes are not part of the supported public REST API. Confirm that Shared run is present in the Desktop build supplied for your installation.