Team & access

Pods uses your Geiger account and your organization's projects. You can open a project in Pods when it belongs to an organization you're a member of, or when you created it as a personal project.

There's nobody to invite inside Pods. To give someone access, add them to the organization in Dash, and to change what they can do, change their organization role there. Settings → General → Project shows your own Inherited role, and Manage in Geiger opens the organization in Dash.

Each person has one of four roles in Pods, taken from their role in the organization that owns the project:

• Owner: the organization's Owner, or the creator of a personal project.
• Admin: organization members whose role is Admin.
• Manager: organization members whose role is Manager.
• Member: everyone else in the organization, whatever their role there, such as User, Leader, Technical Officer or Financial Officer.

A change to someone's organization role changes their Pods role the next time Pods loads the project. Every role sees every entry in the sidebar; what differs is what each one can change or open, as What each role can do describes.

• Owner: everything in Pods.
• Admin: everything an Owner can do, except managing product role grants.
• Manager: builds and releases APIs without the destructive or credential-revealing actions. A Manager can edit resources, routes, methods, integrations, models, authorizers, gateway responses and docs; deploy, edit stages, roll back, flush caches and run test calls; manage API keys (but not reveal their values) and usage plans; read logs, including request and response bodies; and create and edit developer portals (but not publish them). A Manager can't create, edit, delete, import or export APIs, manage secrets, the firewall, domains, connectors, alarms or log exports, generate SDKs, publish portals, change project settings or manage access tokens.
• Member: read-only. A Member can browse the project and read the logs, but can't change anything, and doesn't see request and response bodies.

When a role can't use a screen or an action, Pods hides the button or shows "Access unavailable" in its place.

Settings → Roles & Permissions shows what each role can do, permission by permission. It's read-only: roles can't be created or edited there.

• Roles: each role with its type (System or Custom), key, how many people hold it and how much of Pods it covers. Filter by Type or search. View permissions in a role's ⋯ menu lists every permission it has.
• Permission matrix: every permission against every role. Filter by Group, such as APIs, Build, Release, Consumers, Security, Network, Operations, Distribution and Administration, or search.

The figures across the top count the roles, how many are System and Custom, and the permissions.