Skip to main content
The hosted console creates a personal workspace after your first verified sign-in. A workspace owns its projects and has members; Team is the console page for those members. You can belong to several workspaces. Choose a workspace above the project switcher in the sidebar, then choose a project you can access. Project IDs and project URLs remain stable when team membership changes. The console is currently behind a separate access gate. The recipient of an invitation needs access to that gate and must sign in with the invited email address before accepting. The invitation link identifies an invitation; it does not grant access by itself.

​
Start with a project

A new personal workspace may contain no projects. The optional Get started view offers workspace naming, first test project creation, teammate invitation, and test API key creation. You can skip any step or the entire view and return later from the workspace overview. Owner and Admin can create projects. Only the test environment is available.
Get started checklist with workspace naming, first test project, invitation, and API key steps

Optional setup in the console, captured with mock data from the deployed console source.

​
Roles and project scope

Owners and Admins cover current and future projects. An Operator or Viewer can cover all current and future projects, or only selected project IDs. The invitation dialog previews effective access before you send it. A member with selected projects sees only those projects. The API checks membership and grants on each request; a hidden navigation item is not the security boundary. Workspace Owner is a developer-console role. It does not make someone the owner of a wallet, grant a mandate, or authorize a transaction. A project API key remains bound to one project and environment and cannot manage workspace membership. Account-owner signatures still govern mandate authority.

​
Invite and review

  1. Open Team in the chosen workspace and select Invite teammate.
  2. Enter the recipient’s email, select a role, and choose project scope if the role permits it. Review the effective-access summary, then send.
  3. The recipient opens the invitation, passes the console access gate, and signs in with the invited email. They can accept, decline, or decide later. A pending invitation expires after seven days.
  4. Review its delivery and acceptance state on Team. You can revoke it, or resend a new link that replaces the old one. A failed delivery can be retried.
Invite teammate dialog showing Operator access to all current and future projects

The invitation dialog previews role and project scope before sending. The address is mock data.

Team page showing an Owner and a pending Operator invitation

Team lists members and invitations with their effective scope and state. The addresses are mock data.

Owners can grant any role; Admins can grant only Operator or Viewer. Changing an invitation’s role or project scope requires revoking it and sending a new one. The recipient must explicitly accept before membership is created. A workspace always retains at least one active Owner.

​
Remove a teammate

Open the member on Team and review offboarding before removal. Removal ends that person’s workspace and project access. It does not revoke API keys they created, because keys belong to the project. Review those keys separately and rotate or revoke them where needed. Project data, IDs, mandate records, and audit history remain with the workspace.

​
Use the public API or SDK

Workspace routes require a developer session, not a project API key. The published @gol/sdk@0.6.1 exposes them through GolManagementClient: list workspaces and accessible projects, read members and invitations, create a workspace project, review an invitation before accepting or declining, and review offboarding before removal. Keep the session token server-side. See the SDK API clients and generated reference for method signatures, or the API reference for routes and schemas. The legacy project-creation route still targets your personal workspace. For another workspace, use its explicit workspace project route. Project API keys keep their existing scopes and do not grant team management.