--- version: "2.11.0" language: "en" --- # Understanding Access Groups ## Understanding Access Groups Access Groups are the foundation of Apiboost's product-level access control. They determine which developers and teams can discover, view, and use specific [API Products](https://achieveinternet.atlassian.net/wiki/spaces/AD1/pages/2649982381/API+Products) on the portal. This page explains the concepts behind Access Groups and how they fit into Apiboost's broader security model. ### The Access Control Hierarchy Apiboost uses a layered security model. Understanding each layer helps administrators make informed decisions about how to protect their API Products. **Layer 1: Site Roles (RBAC)** Every user in Apiboost has a site-wide role --- Administrator, Admin, Product Owner, Content Manager, or Developer. These roles control access to administrative functions (managing products, configuring the portal, etc.) but do not control which API Products a developer can see or use. **Layer 2: Product Visibility** Each API Product has a visibility setting that defines the broadest access level. This is the first gate --- it determines who can even discover the product exists. **Layer 3: Access Groups** For products set to "Private" visibility, Access Groups control exactly which developers and teams are granted access. Without an Access Group association, a private product is invisible to all non-admin users. ### Product Visibility Every API Product in Apiboost has a visibility setting that controls how it appears across the portal. This setting works in conjunction with Access Groups to provide fine-grained access control. | Visibility | Product Catalog | Product Detail Page | API References, Docs \& Resources | Who Can Access | |-------------------|-----------------|---------------------|-----------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------| | **Public** | Visible | Visible | Visible | Everyone, including anonymous visitors | | **Restricted** | Visible | Visible | Hidden | Anonymous users can browse and view the product page, but must log in to access API References, Documentation, and Resources associated with the product | | **Authenticated** | Visible | Visible | Visible | All authenticated users --- the product is automatically added to the Authenticated Users group | | **Private** | Hidden | Hidden | Hidden | Only developers and teams explicitly granted access through an Access Group, plus Product Owners and Admins | Product Owners always have access to the products they own, regardless of visibility settings. Administrators and Admins have access to all products by default. ### What is an Access Group? An Access Group is a named container that links three things together: 1. **API Products** --- the products you want to restrict access to 2. **Developers** --- individual users who should have access 3. **Teams** --- groups of developers who should have access collectively When a product's visibility is set to "Private," it becomes invisible to everyone except users who belong to an Access Group that includes that product. #### Example Consider an organization with internal APIs and partner APIs: | Access Group | Products | Developers | Teams | |----------------------|--------------------------|-----------------------------------------------------------------------------------------|--------------------------------| | Internal Engineering | Inventory API, Order API | --- | Engineering Team | | Partner Portal | Catalog API | --- | Partner A Team, Partner B Team | | Beta Testers | Payment API v2 | [jane@example.com](mailto:jane@example.com) , [bob@example.com](mailto:bob@example.com) | --- | In this setup: * Members of the Engineering Team can see the Inventory and Order APIs * Both Partner teams can see the Catalog API, but not the internal APIs * Jane and Bob individually have access to the beta Payment API * All other developers see none of these products (they're private) ### The Authenticated Users Group Apiboost includes a special, system-managed Access Group called the **Authenticated Users** group. This group cannot be deleted or manually edited. When a product's visibility is set to **Authenticated**, Apiboost automatically adds the product to this group. All logged-in users are implicitly members of the Authenticated Users group, so any product with "Authenticated" visibility is accessible to every user with an account. You do not need to manually manage the Authenticated Users group. Products are added and removed automatically based on their visibility setting. ### How Access Is Evaluated When a user attempts to view a product, Apiboost evaluates access in the following order: 1. **Is the user a Product Owner or Admin?** → Access granted (always) 2. **Is the product Public?** → Access granted to everyone 3. **Is the product Restricted?** → Product page visible; API References, Documentation, and Resources require authentication 4. **Is the product Authenticated?** → Access granted to all logged-in users 5. **Is the product Private?** → Check Access Groups: * Is the user a direct member of a group containing this product? → Access granted * Is the user a member of a Team that belongs to a group containing this product? → Access granted * Otherwise → Access denied (product is invisible) ### Group Roles Within each Access Group, members can have different roles: | Role | Capabilities | |------------|------------------------------------------------------------------------------------------------------------------------------------------| | **Member** | Can view products associated with the group. This is the default role for developers added to a group. | | **Admin** | Full group management --- can add/remove products, developers, and teams within the group. Can also edit the group name and description. | Group roles are separate from site-wide roles. A user can be an Admin of one Access Group while being a regular Member of another. ### Relationship to Teams [Teams](https://achieveinternet.atlassian.net/wiki/spaces/AD1/pages/2649982931/Apiboost+Teams) in Apiboost represent groups of developers who collaborate on shared apps. When a Team is added to an Access Group, all members of that team inherit access to the group's products. This means access can be managed at two levels: * **Individual developers** --- added directly to an Access Group * **Teams** --- added to an Access Group, granting all team members access Even though a developer can gain API access from a team, usage is still restricted specifically to **that team's apps** only. When a team member is added or removed from a team, Apiboost automatically recalculates product access permissions. There is no manual step required. ### Relationship to Apps Apps created by developers or teams inherit the product access of their creator. If a developer has access to the Inventory API through an Access Group, they can add the Inventory API to their apps. If they lose access (removed from the group or team), existing app subscriptions to that product are unaffected, but new subscriptions cannot be created. ### Next Steps * [Access Groups: Getting Started](https://achieveinternet.atlassian.net/wiki/spaces/AD1/pages/3114926083/Access+Groups+Getting+Started) --- set up your first Access Group * [How to Manage Access Groups](https://achieveinternet.atlassian.net/wiki/spaces/AD1/pages/3114663940/How+to+Manage+Access+Groups) --- task-based guides for common operations