Outcome
Read the saved Developers onboarding/profile state and selected-workspace summary before deciding whether a separately authorized next task is available.
GET /api/developer-console/onboarding
Before you start
Use the original authenticated organization with the published Developers apps:read permission. Discover and separately bind an accessible canonical Developers workspace. This action accepts exactly an empty input object {}; appId, workspaceId, cursor, limit and filters are not admitted input fields.
This GET permits a suspended developer-profile read but refuses revoked access; completed onboarding is not a prerequisite to read the onboarding state. It resolves a developer profile and selected workspace, not a particular app record. A saved owner/profile/management flag is not proof of a later write’s permission or workspace access level.
This is the developer onboarding/profile read, not a workspace creation, signup completion, subscription charge or API-key grant. Use its saved state to understand what remains, then separately discover and authorize any intended change.
The shared request path can insert a local identity-only workspace mirror and, for an enabled organization without a developer profile, create the initial developer profile after resolving a platform-issued workspace. This can precede app access refusal. No canonical Auth workspace is minted, and readOnly metadata is not a promise of zero initialization writes.
All worked responses are source-derived synthetic UNRUN examples. No real developer app, declaration, provider, key, person, private record, publication or other business action was read or changed. The immutable source matches the retained declaration revision; serving-runtime adoption is not independently proven.
Request and behavior
Action: app_topolo_developers.workspace.onboarding.get.
{}
Bind the discovered canonical workspace separately in the original context and validate/plan against the current schema before a real call.
The exact HTTP200 envelope is {success:true,message,data:{workspace,developer}}. Input is exactly {}; bind the discovered canonical Developers workspace separately. The current structural response schema permits this carrier but does not precisely enumerate all profile/summary semantics.
Shared context authenticates, loads the organization developer profile and verifies the ordinary same-organization workspace through Auth at read level. A recognized privileged cross-organization platform branch instead uses the seeded profile workspace and does not honor an input header on that branch. Missing profiles for enabled organizations can initialize after platform workspace resolution, and local mirrors can be inserted. No canonical Auth workspace is created by this GET.
workspace is the buildWorkspaceSummary projection: workspaceId,organizationId,organizationName,organizationSlug,ownerUserId,accessStatus,onboardingState,reviewState,onboardingStep,source,appCount,pendingListings,requestCount,canManageApps,canManageCredentials,supportEmail. ownerUserId falls back to the authenticated user when profile userId is absent; it is a projected value, not a new ownership grant.
This onboarding handler deliberately calls buildWorkspaceSummary with empty app and request arrays. Its workspace.appCount,pendingListings,requestCount are therefore zero placeholders for this read, not queries certifying an empty portfolio, no pending submissions or no build requests. developer.appCount/appsSubmitted/appsApproved remain the separate organization-wide profile-query counts. These two count surfaces can differ without a failed request.
canManageApps and canManageCredentials are computed only from developer.accessStatus active and onboardingState complete. They do not check concrete action permission, app actor edit/transfer role, actual selected workspace write/admin grant, caller-specific Auth API-key options, commercial policy or any future source state. A true value cannot authorize a mutation or key operation; a suspended profile yields false while this GET itself is still allowed.
developer is the full resolved profile, with selected workspaceId replacing its stored default. It includes profile identity, organization/name/email/company/website, subscription-plan preference, access/review/onboarding state and step/completion timestamp, use-case/app ideas/support/operational contacts/location/needs/intent, organization-wide app/submission counts, source and timestamps. Those values remain authorized organization data; public documentation does not publish actual contacts or business ideas.
The profile mapper defaults unrecognized/nonannual subscription preference to monthly, accesses profile metadata fields as saved strings, and supplies read-time timestamp fallbacks. These are display mappings, not paid subscription, payment, accepted review, completed verification or persisted-data repair proof. OnboardingState complete and reviewState approved remain distinct saved dimensions.
The selected handler does not list app rows/build requests, complete onboarding, create or edit an app, mint a key, publish a manifest, invoke a provider or send a notification. Shared initialization can occur before later refusal, so readOnly metadata is not a global zero-write guarantee.
Worked responses
Completed saved onboarding with coarse management flags
Complete source-derived synthetic UNRUN HTTP200 for an active fictional profile with complete onboarding, no configured supportEmail and an original owner email. workspace.supportEmail therefore falls back to profile.email. This handler passes empty arrays, so workspace counters are0 even while developer.appCount is1 organization-wide.
{
"success": true,
"message": "Developer onboarding state fetched successfully",
"data": {
"workspace": {
"workspaceId": "ws_docs_fixture",
"organizationId": "org_docs_fixture",
"organizationName": "Fixture organization",
"organizationSlug": "fixture-org",
"ownerUserId": "usr_docs_fixture",
"accessStatus": "active",
"onboardingState": "complete",
"reviewState": "unreviewed",
"onboardingStep": 1,
"source": "developer-console",
"appCount": 0,
"pendingListings": 0,
"requestCount": 0,
"canManageApps": true,
"canManageCredentials": true,
"supportEmail": "owner@fixture.invalid"
},
"developer": {
"id": "dev_docs_fixture",
"userId": "usr_docs_fixture",
"organizationId": "org_docs_fixture",
"organizationName": "Fixture organization",
"organizationSlug": "fixture-org",
"workspaceId": "ws_docs_fixture",
"name": "Fixture owner",
"email": "owner@fixture.invalid",
"companyName": "Fixture organization",
"websiteUrl": "",
"subscriptionPlan": "monthly",
"accessStatus": "active",
"reviewState": "unreviewed",
"onboardingState": "complete",
"onboardingStep": 1,
"onboardingCompletedAt": "2026-10-20T08:00:00.000Z",
"summary": "",
"useCase": "",
"appIdea": "",
"firstAppName": "",
"firstAppCategory": "",
"supportEmail": "",
"operationalContactName": "",
"operationalContactEmail": "",
"location": "",
"companySpecificNeeds": "",
"communityBenefitIdea": "",
"intent": "",
"appCount": 1,
"appsSubmitted": 0,
"appsApproved": 0,
"source": "developer-console",
"createdAt": "2026-10-20T08:00:00.000Z",
"updatedAt": "2026-10-21T08:00:00.000Z"
}
}
}
Read the saved states and counter meanings, then check actual current action/workspace/actor/key eligibility for any separate authorized operation; true management flags are not grants.
Suspension permits reading but disables management flags
Complete synthetic UNRUN HTTP200 for the same fictional profile with accessStatus suspended. This GET opts into suspended reads and both coarse management flags become false. No actual suspension or private profile read occurred.
{
"success": true,
"message": "Developer onboarding state fetched successfully",
"data": {
"workspace": {
"workspaceId": "ws_docs_fixture",
"organizationId": "org_docs_fixture",
"organizationName": "Fixture organization",
"organizationSlug": "fixture-org",
"ownerUserId": "usr_docs_fixture",
"accessStatus": "suspended",
"onboardingState": "complete",
"reviewState": "unreviewed",
"onboardingStep": 1,
"source": "developer-console",
"appCount": 0,
"pendingListings": 0,
"requestCount": 0,
"canManageApps": false,
"canManageCredentials": false,
"supportEmail": "owner@fixture.invalid"
},
"developer": {
"id": "dev_docs_fixture",
"userId": "usr_docs_fixture",
"organizationId": "org_docs_fixture",
"organizationName": "Fixture organization",
"organizationSlug": "fixture-org",
"workspaceId": "ws_docs_fixture",
"name": "Fixture owner",
"email": "owner@fixture.invalid",
"companyName": "Fixture organization",
"websiteUrl": "",
"subscriptionPlan": "monthly",
"accessStatus": "suspended",
"reviewState": "unreviewed",
"onboardingState": "complete",
"onboardingStep": 1,
"onboardingCompletedAt": "2026-10-20T08:00:00.000Z",
"summary": "",
"useCase": "",
"appIdea": "",
"firstAppName": "",
"firstAppCategory": "",
"supportEmail": "",
"operationalContactName": "",
"operationalContactEmail": "",
"location": "",
"companySpecificNeeds": "",
"communityBenefitIdea": "",
"intent": "",
"appCount": 1,
"appsSubmitted": 0,
"appsApproved": 0,
"source": "developer-console",
"createdAt": "2026-10-20T08:00:00.000Z",
"updatedAt": "2026-10-21T08:00:00.000Z"
}
}
}
Retain the suspended state and original context. A successful GET does not authorize an onboarding/app/key write or a way around suspension.
Revocation refuses the read
Complete synthetic UNRUN HTTP403 from the shared revoked-profile check instead of a successful empty state. Shared initialization and earlier context effects are separate; no real revocation or denial was induced.
{
"success": false,
"error": {
"message": "Developer workspace access has been revoked. Contact Topolo support if this is unexpected."
}
}
Preserve actual refusal/request id and legitimate owner custody. Do not alter organization, role, access status or workspace to bypass it.
Verify and recover
-
Compare actual data.workspace and data.developer organization/workspace identity to the original separately bound context. ownerUserId fallback is not proof of an ownership change.
-
Interpret each saved access/onboarding/review field separately. Treat zero workspace counts as this handler’s empty-array placeholders; profile totals are organization-wide and can be positive.
-
Do not consume canManageApps/canManageCredentials as permission grants. Discover/validate/plan the concrete later action and its actual resource and caller policy independently.
-
Preserve private profile/contact/use-case data within the approved reader audience and retain actual refusal/consistency evidence. No initialization cleanup, profile edit, key mint, signup completion or provider operation is automatic recovery.
Change log
- 2026-10-21: Added exact onboarding/profile carrier, placeholder-count versus organization-count semantics, coarse management-flag limits and suspended-read/revoked-refusal behavior, with complete synthetic unrun examples. No operational state or entitlement was changed.