Get Success identity context

Outcome

Return verified Auth user and optional organization projections without resolving or creating a Success workspace. Canonical workspace discovery and creation remain Auth-owned.

Before you start

• Verify the authenticated identity, exact environment and pinned approved organization context before preparing an action.
• The published application permission is workspace:read. The credential context supplies identity and organization; these actions do not resolve a workspace.

Discover the target

topolo whoami --json
topolo actions get app_topolo_success.workspace.bootstrap --detail --json

Request

GET /api/bootstrap

Save action input as payload.json. Inspect the plan for the exact path, query and body.

Inspect and test this action in the signed action console, then perform the verification below.

Input fields

Supply an empty input object; credential and resource context are separate.

Exact input schema:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {},
  "additionalProperties": false
}

Effects

• Returns the verified user and organization projections; no Success workspace mirror or domain record is created.

Interpret the response

Use response path $.user.id for user. An empty list does not discover a target.

Check user.id and organization.id against the intended identity/context. This does not list workspaces or grant access. Use topolo workspaces list topolo-success and its caller-specific policy for canonical workspace operations.

The success schema below was checked against captured handler responses. Delegated Auth profile fields and sanitized notification payload fields can vary; exact outer envelopes and SQL row fields are source-reviewed. Error examples retain their actual refusal shapes.

Success schema:

{
  "type": "object",
  "properties": {
    "user": {
      "type": "object",
      "properties": {
        "id": {
          "type": "string",
          "description": "Source-defined string field."
        },
        "email": {
          "type": "string",
          "description": "Source-defined string field."
        }
      },
      "required": [
        "id",
        "email"
      ],
      "additionalProperties": true,
      "description": "Verified Auth identity projection; optional context, permissions and profile fields are owned by Auth and can vary."
    },
    "organization": {
      "anyOf": [
        {
          "type": "object",
          "properties": {
            "id": {
              "type": "string",
              "description": "Source-defined string field."
            },
            "slug": {
              "type": "string",
              "description": "Source-defined string field."
            },
            "name": {
              "type": "string",
              "description": "Source-defined string field."
            }
          },
          "required": [
            "id"
          ],
          "additionalProperties": true,
          "description": "Auth organization projection; null is possible for a personal identity."
        },
        {
          "type": "null"
        }
      ]
    }
  },
  "required": [
    "user",
    "organization"
  ],
  "additionalProperties": false
}

Worked examples

Actual exported Worker responses captured with real local SQLite D1 and all committed migrations, synthetic Auth identity/grants, simulated Notify/Nexus and canonical archive transport. Fixture ids are examples only. No live notification delivery, metering acceptance, privacy erasure, workspace archive or deployment is established by these tests. Refused examples demonstrate boundaries and must not be executed as successful workflows.

Successful request

Actual exported Worker response with real local SQLite D1, synthetic Auth/grants and simulated Notify/Nexus/archive transport; no live delivery or deployment proof. Captured scenario: workspace.bootstrap.

Input · payload.json:

{}

CLI:

topolo actions validate app_topolo_success.workspace.bootstrap --data @payload.json --json
topolo actions plan app_topolo_success.workspace.bootstrap --data @payload.json --json
topolo actions call app_topolo_success.workspace.bootstrap --data @payload.json --json

MCP tool and arguments:

{
  "tool": "topolo_read_action",
  "arguments": {
    "actionId": "app_topolo_success.workspace.bootstrap",
    "input": {}
  }
}

Captured local response · HTTP 200:

{
  "user": {
    "id": "usr_success_fixture",
    "email": "operator@example.test",
    "orgId": "org_success_fixture",
    "role": "member",
    "permissions": [
      "*"
    ],
    "organization": {
      "id": "org_success_fixture",
      "slug": "success-fixture",
      "name": "Synthetic fixture"
    },
    "orgSlug": "success-fixture",
    "activeContextType": "organization",
    "activeContextId": "org_success_fixture"
  },
  "organization": {
    "id": "org_success_fixture",
    "slug": "success-fixture",
    "name": "Synthetic fixture"
  }
}

HTTP 200. Check user.id and organization.id against the intended identity/context. This does not list workspaces or grant access. Use topolo workspaces list topolo-success and its caller-specific policy for canonical workspace operations.

Verify the result

• Check user.id and organization.id against the intended identity/context. This does not list workspaces or grant access.
• Use topolo workspaces list topolo-success and its caller-specific policy for canonical workspace operations.

Errors and recovery

• invalid_action_input (HTTP 400): Correct only the input paths reported by the runtime or CLI validator; retain action id and exact context.
• action_permission_required (HTTP 403): The verified credential lacks the action permission. Stop this action and request the appropriate authorized grant; an identifier or organization ownership does not grant it.

Auth, action-input validation and platform resource resolution can refuse a request before its handler. Retain the exact error, request id and context; requesting another context is not a legitimate way to bypass a refusal.

Recovery boundary

Identity projection has no local mutation to reverse.

Related actions

• List Success customer accounts: List all customer accounts in the authorized workspace, ordered by latest update and then name. There is no pagination; the request can create the local workspace identity mirror.

Evidence

Actual exported Worker responses captured with real local SQLite D1 and all committed migrations, synthetic Auth identity/grants, simulated Notify/Nexus and canonical archive transport. Fixture ids are examples only. No live notification delivery, metering acceptance, privacy erasure, workspace archive or deployment is established by these tests. Capture digests and test scenarios are retained in the source fixture records.