Business Tenant Governance
Business tenants (also called enterprise tenants) unlock a set of governance controls that operate across all the APIs and applications in the tenant — above the per-collection access rules and security policies that govern an individual API.
This page is the map. Each control has its own page or section; the table below links to them and tells you where each is configured and who can change it.
These controls require a Business tenant. On a standard tenant the panels described here don't appear, and each API is governed solely by its own roles, access rules, and security policies. The one exception is the IP allowlist, which is available to every tenant.
The governance controls
| Control | What it governs | Scope | Where to configure | Who |
|---|---|---|---|---|
| Application access | Which roles may open an application (web app bundle) | Per API | Application → General, or Control Center → Access Review | Tenant admin |
| Cross-API access | Which other APIs in the tenant may call this API | Per API | API → Settings → Cross-API access | Tenant admin |
| IP allowlist | Which client IPs may reach the API and app | Per API (all tenants) | API → Security → IP Whitelist | API contributor |
| Access Review | Audit what a role or user can actually reach | Tenant-wide | Control Center → Access Review | Tenant admin |
| Kill switch | Take an entire API online / offline | Per API | Control Center → Monitoring | Tenant admin |
| Monitoring | Traffic, errors, quota, and cost per API | Tenant-wide | Control Center → Monitoring | Tenant admin |
| Cost governance | Credit caps and per-API spend thresholds | Tenant-wide | Control Center → Cost Management | Tenant admin |
The first three (application access, cross-API access, IP allowlist) are enforcement controls — they change who can reach what at request time. The rest live in the Control Center and are about observing and operating the tenant.
Linked applications
A Business tenant can run several applications that are linked together under one master application. This is the model the governance controls build on, so it's worth understanding once.
- A master and its siblings. One API in the tenant is the master; the others are linked to it. Together they form a single suite a user can move between.
- A directory of the apps you can reach. From any app in the suite, a signed-in user can list the linked applications. That directory is role-filtered — it shows only the siblings whose application-access gate the user passes (an app with no role restriction is visible to everyone; the user's own app is always listed). Offline and quota-exceeded siblings are omitted.
- One sign-in, many apps. A user authenticated against one app in the suite
can move to a sibling without signing in again, provided they are provisioned
on that sibling. Crossing into a sibling still honours that sibling's
application access (a missing role →
403) and the cross-API access allow-list for app-to-app data calls.
Linking is set up at the tenant level. Once linked, the access rules, application-access gates, and cross-API allow-lists on each member API continue to apply independently — linking changes navigation and reach, never the underlying authorization of any single API.
How the controls layer together
For a request into a linked Business-tenant application, the governance controls apply roughly in this order, each able to stop the request on its own:
- API status — if the target API is offline/suspended, the request is rejected outright.
- IP allowlist — if configured and the client IP isn't listed, the request is rejected.
- Application access — opening the app requires a matching role (or an empty, open allow-list).
- Cross-API access — an app-to-app call into a sibling requires the caller to be on the target's allow-list.
- Access rules + security policies — finally, the specific collection/query/function authorizes the operation and filters rows.
Note the differing defaults, which are easy to get wrong:
- Application access and the IP allowlist are fail-open: an empty list means no restriction.
- Cross-API access is fail-closed: with nothing configured, no other API may call this one.
See also
- Application Access — gate an app to specific roles
- Cross-API Access — authorize API-to-API calls
- IP Allowlist — restrict access by client IP
- Control Center — monitoring, access review, and cost management