> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gol.network/llms.txt
> Use this file to discover all available pages before exploring further.

# Workspaces and team access

> Organize projects, invite teammates, and review each person's effective access.

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.

<Frame caption="Optional setup in the console, captured with mock data from the deployed console source.">
  <img src="https://mintcdn.com/gol-docs/D0jAq5PWXsm4zG5Y/images/console/create-project.png?fit=max&auto=format&n=D0jAq5PWXsm4zG5Y&q=85&s=b13eed18addfc3df91cf82b1762ba359" alt="Get started checklist with workspace naming, first test project, invitation, and API key steps" width="1824" height="1100" data-path="images/console/create-project.png" />
</Frame>

## Roles and project scope

| Capability | Owner | Admin | Operator | Viewer |
| - | - | - | - | - |
| Read project overview, gas activity, and permitted audit history | All projects | All projects | Assigned projects | Assigned projects |
| Edit a project name; manage test keys and webhooks | All projects | All projects | Assigned projects | No |
| Open a charge dispute | Yes | Yes | No | No |
| Create projects; rename the workspace | Yes | Yes | No | No |
| Invite or remove Operators and Viewers | Yes | Yes | No | No |
| Grant or remove Owners and Admins | Yes, with recent verification | No | No | No |

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.

<Frame caption="The invitation dialog previews role and project scope before sending. The address is mock data.">
  <img src="https://mintcdn.com/gol-docs/D0jAq5PWXsm4zG5Y/images/console/team-invite.png?fit=max&auto=format&n=D0jAq5PWXsm4zG5Y&q=85&s=e73226f70c3093df2f8358c3aa3ba26a" alt="Invite teammate dialog showing Operator access to all current and future projects" width="2400" height="1800" data-path="images/console/team-invite.png" />
</Frame>

<Frame caption="Team lists members and invitations with their effective scope and state. The addresses are mock data.">
  <img src="https://mintcdn.com/gol-docs/D0jAq5PWXsm4zG5Y/images/console/team.png?fit=max&auto=format&n=D0jAq5PWXsm4zG5Y&q=85&s=16504cb6bf8edce2bd2f815ffaecd609" alt="Team page showing an Owner and a pending Operator invitation" width="1824" height="904" data-path="images/console/team.png" />
</Frame>

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. Published `@gol/sdk@0.7.1` retains the `GolManagementClient` methods introduced in 0.6.1: 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](/sdk/api-clients) and [generated reference](/sdk/reference) for method signatures, or the [API reference](/reference/overview) 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.