Decide Exactly Who Sees Each API — and Who Doesn't
Access Groups give you granular, product-level control over API visibility. Assign teams and individual developers to groups, link those groups to API products, and private APIs become invisible to everyone else — not restricted, invisible.
No shared passwords. No network-level workarounds. Just a clean permissions model that scales with your organization.
What Happens Without Product-Level Access Control
Authentication answers "is this person logged in." It doesn't answer "should this person see this API." That gap creates real problems.
All-or-Nothing Visibility
Every authenticated user sees every API in your catalog. Internal endpoints, partner APIs, premium tiers — all exposed to anyone with a login.
Shared Credentials and Workarounds
Teams resort to shared passwords, Basic Auth middleware, or IP whitelisting to keep the wrong people out of the wrong docs. None of it scales.
Docs Leak What Keys Protect
API keys guard the runtime layer. But your documentation exposes schemas, parameters, and error codes to anyone who can see the page — including AI crawlers.
No Partner Segmentation
You can't give Partner A access to the Billing API without also exposing the Settlement API to Partner B. Every partner sees the same catalog.
Your Developer Portal should control who sees each API — not just who can call it. Access Groups make that possible without custom middleware or network hacks.
How Access Groups Work
Three objects. One relationship. Complete control over which developers can discover which APIs.
Create an Access Group:
Name the group for its purpose — "Premium Partners," "Internal Engineering," "Beta Testers." Each group is an independent scope of access.
Add API Products:
Assign the specific API products this group should access. Products set to Private visibility are completely invisible to anyone outside the group.
Add Teams and Developers:
Assign teams or individual developers. Team members inherit access automatically — when someone joins a team, they see the APIs. When they leave, the APIs vanish.
A private API in Apiboost isn't restricted — it's invisible. No catalog listing. No search results. No documentation page. It doesn't exist to a user who isn't in the right group.
Four Visibility Tiers. One Clear Model.
Access Groups unlock the Private tier — the most restrictive level of product visibility. Here's how all four tiers compare.
Visibility Tier | In Catalog | Product Page | API Docs | Who Can Access |
✔️ | ✔️ | ✔️ | Everyone, including anonymous visitors | |
✔️ | ✔️ | Requires login | Product page is public; docs require authentication | |
✔️ | ✔️ | ✔️ | All logged-in users | |
- | - | - | Only users in an assigned Access Group |
Built for Real Access Patterns
Access Groups map to the way enterprises actually segment API access — not the way authentication systems assume they do.
Partner API Programs
Each partner organization gets an Access Group with exactly the API products they've been contracted to use. Partner A sees the Billing API; Partner B sees Logistics. Neither sees the other's.
Internal-Only APIs
Keep internal APIs — admin tools, settlement systems, infrastructure endpoints — completely hidden from external developers. Your engineering team sees them; nobody else knows they exist.
Beta and Early Access
Roll out new API versions to a select group of developers before general availability. When the beta closes, remove the Access Group assignment — the APIs disappear from their catalog instantly.
Monetized API Tiers
Free-tier users see the public market data APIs. Paying customers get an Access Group that includes premium trading, analytics, and webhooks. The upgrade path is access, not infrastructure.
Permissions That Scale With Your Org Chart
Access Groups support both individual developers and teams. When you add a team to a group, every member inherits access immediately. When someone joins the team, they get the APIs. When they leave, the APIs vanish.
No manual provisioning per developer. No stale permission lists to audit. Your Access Groups stay accurate because they follow your organization's actual structure.
Part of a Complete Access Model
Access Groups are one layer of Apiboost's security model. They work alongside RBAC and SSO to cover every dimension of access control.
Role-Based Access Control
RBAC controls what users can do on the portal — manage products, publish docs, configure settings. Access Groups control what users can see. Both layers together mean the right people have the right capabilities on the right APIs.
Single Sign-On (SSO)
Federate login to your identity provider — Okta, Auth0, Microsoft Entra ID. Users are auto-provisioned with roles on first login. Disable local passwords entirely and let your IdP handle MFA and session policies.
Product Visibility Tiers
Four tiers — Public, Restricted, Authenticated, Private — give admins graduated control over each API product's discoverability. Access Groups unlock the Private tier, where products vanish from unauthorized views entirely.
Related Blog Posts:
Danfoss API Portal Transformation: A Case Study in Innovation in Digital Transformation
Developer Portals and API Documentation Localization: Best Practices to Drive Global Adoption
Webhook Support now available in Apiboost
Access Groups give you per-API, per-team visibility control without custom middleware, network-level hacks, or shared passwords.
Ready to Control Who Sees Your APIs?
Apiboost gives enterprises product-level visibility control from a single admin interface. Access Groups are how you make "private" actually mean private.
Create Access Groups in seconds — name the group, add products, assign teams
Private API products disappear entirely from unauthorized users' catalogs, search results, and portal navigation
Team-based assignment means permissions scale with your org structure — no per-user provisioning
Combine with RBAC and SSO for defense-in-depth across authentication, authorization, and visibility