How to Configure Enterprise Policies in Apidog

Enterprise Policies apply organization-wide rules to credential handling, member admission, SSO session access, and invitation rewards. Organization Owners and Admins can configure these policies from the organization's security settings.

This tutorial explains the scope of each policy, how to configure it, and what to test before wider rollout.

Before you start

• The organization must use the Enterprise plan.
• You must be an Organization Owner or Organization Admin.
• The policies available in Apidog On-Premises may differ from the SaaS documentation.
• Use test users, fictional credentials, and a non-production project for validation.

These are workspace policies. They do not replace runtime controls in an API gateway, authorization server, service mesh, or application.

Step 1: Open Enterprise Policies

1. Open the Apidog organization.
2. Go to Organization Settings.
3. In Security, select Enterprise Policies.

Only Organization Owners and Admins can change Enterprise Policies.

The page currently includes four policies:

• Auth Credential Policy
• Invitation Credit Policy
• SSO Session Policy
• Member Email Domain Policy

Step 2: Configure Auth Credential Policy

Auth Credential Policy checks supported sensitive authentication fields when users edit or save API authentication, folder authentication, request authentication, security schemes, API test cases, and test scenarios.

Choose the raw-value mode

Configure Forbid raw values in Auth sensitive fields:

Choose the reference mode

Configure Allow only local variables or Vault Secret in Auth with the same Off, Warn, or Block modes.

When this control is enabled, sensitive fields should use local-only variables or Vault Secret references. A variable with a shared initial value may warn or block according to the selected mode.

Apidog treats the following as allowed references for the credential policy:

• an empty value;
• a variable reference such as {{variableName}};
• a Vault Secret reference such as {{vault:key}}.

Control Vault value display

Enable Vault Secret cannot be revealed in plaintext when users should not be able to display Vault Secret values in the UI.

Test before blocking

For a controlled rollout:

1. use Warn in a pilot project;
2. test API Key, Bearer Token, Basic Auth, OAuth 2.0, and any other authentication types used by the organization;
3. replace raw values with the approved variable or Vault pattern;
4. confirm that legitimate workflows still save and run;
5. move to Block when the exceptions have been addressed.

The policy covers documented sensitive fields across API Key, Bearer Token, Basic and Digest Auth, OAuth 1.0 and 2.0, Hawk, AWS, NTLM, Akamai EdgeGrid, JWT Bearer, and combination authentication.

Step 3: Configure SSO Session Policy

SSO Session Policy controls whether users can access My Teams while signed in through the current organization's SSO.

1. Confirm that SSO is configured for the organization.
2. On Enterprise Policies, find SSO Session Policy.
3. Enable Restrict My Teams in SSO sessions.
4. Save the policy.

When enabled, My Teams is unavailable during that organization's SSO session.

The setting is disabled by default and can be enabled only after SSO is configured. A restricted user must sign out and use a regular sign-in method to access My Teams. Returning to the SSO organization requires signing in through SSO again.

This policy is not an idle timeout or a maximum session-duration setting. It isolates My Teams access within the current organization's SSO session.

Test the session boundary

Use a non-admin test user:

1. sign in through the organization's SSO entry point;
2. confirm that the organization is available;
3. attempt to open My Teams and confirm the restriction message;
4. select Sign out and switch;
5. sign in with a regular method and confirm that My Teams is available;
6. confirm that returning to the SSO organization requires SSO.

Step 4: Configure Member Email Policy

Member Email Policy limits organization membership to approved email domains. Apidog checks the user's final authenticated email, not only the address to which an invitation was sent.

1. Configure one or more allowed email domains for the organization.
2. Open Security > Enterprise Policies.
3. Find Member Email Policy.
4. Enable the policy and save it.

Configure the domains whose authenticated users may become organization members.

The same admission rule applies to:

• email invitations;
• invitation links;
• SSO;
• SCIM.

If the final authenticated email does not match an allowed domain, Apidog rejects the join attempt. No Organization, Team, or Project membership is created, the user does not occupy a seat, and the user does not appear in the member list or member export.

A rejected user receives a domain-mismatch message, and the rejection is recorded in Audit Logs.

Test at least one approved address and one disallowed address for each admission route the organization uses.

Step 5: Configure Invitation Reward Policy

Invitation Reward Policy controls whether eligible organization-related invitations can generate invitation reward Credits.

1. Open Security > Enterprise Policies.
2. Find Invitation Reward Policy.
3. Enable or disable invitation rewards.
4. Save the setting.

Disabling the policy stops future eligible organization-related invitations from generating reward Credits. It does not remove Credits already earned.

This is an administrative setting, not an access-control or security policy. It should not be described as an invitation-email suppression feature.

Verify all four policies

Use a small test matrix and record the result.

After testing, review Audit Logs for the supported policy-related membership or rejection events that are relevant to the workflow.

Troubleshooting

Important limitations

• Auth Credential Policy applies to documented authentication fields and workflows, not every free-text field, script, file, or external repository.
• SSO Session Policy restricts My Teams in one organization's SSO session; it is not a session timeout, device policy, or network control.
• Member Email Policy governs admission. Do not assume it automatically removes existing members whose addresses no longer match unless that behavior is separately documented and tested.
• Invitation Reward Policy is not a security control.
• None of these policies enforces authentication or authorization on deployed API traffic.

Related API governance tutorials:

These tutorials cover complementary controls for governing an enterprise API workspace:

• API Governance Framework — connect ownership, controls, evidence, and lifecycle decisions.
• SAML Group Mapping with Microsoft Entra ID — assign team access from identity-provider groups.
• Secret Scanner — review possible exposed credentials in supported Apidog assets.
• Audit Logs — investigate and export administrative organization activity.
• SCIM Provisioning — manage organization users through the identity lifecycle.
• Enterprise Policies — configure credential, membership, SSO-session, and invitation controls.
• Self-Service API Teams — allow member-created teams while retaining ownership oversight.
• GitHub Enterprise Cloud Integration — connect supported GHE.com repositories for OpenAPI workflows.

Related official documentation:

• Enterprise Policies
• Vault Secret in Apidog
• Secret Scanner
• SSO Overview
• Audit Logs