Users and organizations

All users in 42Crunch API Security Platform have a user account that allows them to access the platform, its services, and resources that have been allocated to them. All users are properly authenticated and their authorization checked when they log in on the platform. For auditing purposes, the actions users take on the platform are logged with their user IDs. This way, harmful user actions can be traced back to the compromised user account and the account locked to prevent any further damage.

User accounts

There are two types of user accounts in 42Crunch Platform, community users and business users. You can check which one your account is based on the organization it belongs to.

All users can manage their own account settings.

Users cannot change their username (the email address they use to log in to the platform) or the organization they belong to.

Community users

The accounts of all community users belong to the free Community organization that is managed by 42Crunch.

Some features of the platform may have limitations for community users or might not be available at all. However, you can upgrade to a business user and choose a suitable subscription plan for your needs at any time.

Business users

For businesses, 42Crunch creates a dedicated organization for the company in questions as well as an account for an organization administrator. It is the organization administrator who then onboards the rest of the users to the organization. All onboarded accounts belong to the organization of the company.

Business users can use all the features in the platform. The subscription plan may impose limits to things like number of users or APIs in an organization. Again, the subscription plan may be upgraded at any time.

User roles

User accounts in 42Crunch Platform can have three kinds of user roles:

  • Regular user: Most users in the platform are regular users. They can manage their own user profile and APIs and API collections they own, but not those of other users unless explicitly given the access through collection sharing. They also cannot themselves change the permissions assigned to their accounts. All users in the free community organization are regular users.
  • Organization administrator: Organization administrators can manage all users and their permissions and all APIs, API collections, and other features and settings in their organizations, as well as the subscription plans. For businesses, organization administrators are privileged users in their own organization. For users in the free community organization, 42Crunch is the organization administrator.
  • Auditor: Auditor is a special user role that provides read-only access to everything in the organization that an organization administrator has: the users and their permissions, all APIs and API collections, reports, teams, tags, security quality gates, customization rules, and so forth. However, auditors cannot modify any data (except their own name and password) in the organization, merely view it. This role is intended, for example, users external to the organization but who require access to the assets the organization has in 42Crunch Platform to audit the organization's compliance with standards or regulations. The auditor role is not available in the free community organization, only for business users.


Access to some functions in 42Crunch Platform, like running API Conformance Scan, sharing API collections, or managing teams, is controlled with permissions. To be able to perform the action, your user account must have permission to do so. What you can do by default depends on the type of your account:

  • If you are a user in the free community organization, by default you cannot run Conformance Scan in 42Crunch Platform or share API collections. You can still run Conformance Scan on premises. For more details, see API Conformance Scan.
  • If you are an organization administrator, you have all permissions by default.
  • If you are an onboarded user in the organization of a specific company but not an organization administrator, your default permissions depend on what your organization administrator has defined for you.

Auditors cannot receive any permissions.

The permissions are managed by organization administrators. If you need a permission you do not currently have, contact your organization administrator.

If you are an organization administrator and want to see who can do what in your organization, you can search users by permission. For more details, see Manage user permissions.


In 42Crunch Platform, both users and resources always belong to organizations that are managed by organization administrators.

When a user account is created, it is always created in an organization. The resources (API collections and APIs) users create or import also belong to the same organization as them. Both accounts and resources can only belong to one organization that cannot be changed.

Sharing API collections is also done at the organization level: when you share an API collection, you can choose who in your organization can view or edit the APIs in it. Note that you cannot give auditors editing rights to your APIs even through sharing.

Organization administrators

In addition to their own account, organization administrators can manage other users in their organizations, onboard the rest of the users in their company that need an account to the platform, and manage the subscription plan of their organization.

A screenshot showing the Users tab from the organization settings.

To manage users, organization administrators can:

  • Add or delete user accounts in their organization
  • See which APIs and API collections each user owns
  • Change user roles, such as promote new organization administrators
  • Force password reset for a user account
  • Lock a user account that shows suspicious or harmful activity

For businesses, organization administrators are privileged users in their own organization. For users in the free community organization, 42Crunch is the organization administrator.

Organization administrators can see how many collections and APIs each user in their organization has. Organization administrators can also manage all API collections in their organization, and create a scan configuration and run Conformance Scan on premises on any APIs in their organization.

Organization administrators have access to view and modify all API collections in their organization. This means that all API collections in an organization are visible to all organization administrators like the collections were their own, both on the API Collections page and in the monitoring dashboards. If an organization has several API collections, we recommend using more descriptive collection names that just organization and company name to be able to tell all collections apart.

To avoid losing things like APIs and API collections, tags and tag categories, customization rules and security quality gates (SQGs), when organization administrators delete a user account, they must first transfer the assets related to that user account to someone else before the account can be deleted. If the deleted user was a team lead in any teams, those roles are also transferred to the new owner of the assets.

To ensure that an organization always has at least one organization administrator, organization administrators cannot lock or delete their own account, nor can they remove their administrative rights. However, they can still do this to other organization administrators in their organization.


By default, new users are either added when they self-register to the platform, or when organization administrators manually create accounts for them. But there is a third way: with user invitations, organization administrators can invite people to join their organization.

An example screenshot of the invitation dialog

When you invite users to join your organization, you predefine some settings for their user accounts, such as permissions, and whether they are organization administrators, just like when you manually create an account. When a user follows the invitation to log in to the platform, the user account is created in your organization.

There are two ways to invite people to your organization:

  • Email: An invitation mail with a client token is send to the email address of your user. This saves you the trouble of having to send a notification mail with the account details yourself. The email address also becomes the username of that user, because the client token is only valid for that email. This is the default and more secure option.
  • Link: An invitation link with a client token is generated and you can copy and share it to your user as you want. Anyone with a valid invitation link can log in to the platform, so be mindful how you share the link.

You can choose if you want to allow both invitation methods. Both invitation mails and links expire after a specified time. For invitation mails, you can choose the expiration time from five minutes to a week. Invitation links always expire after 15 minutes.

Mail invitations can be combined with SSO, and there are multiple options on how that can be done:

  • The invitations can be restricted to only email addresses that are outside your SSO domains. Users in your SSO domain cannot be invited to join your organization but must self-register or be created manually.
  • The invitations can be restricted to only email addresses within your SSO domains. Users outside your SSO domain cannot be invited to join your organization but must be created manually.
  • Anyone can be invited to join your organization, regardless of the domain of their email address.

For invitation links in SSO, you must select which SSO domain the link applies to. Only users from that particular email domain can register through the invitation link.

User invitations are switched off by default, and you cannot change the settings for invitation method yourself. If you would like to enable this feature in your organization or change its settings, contact 42Crunch support and let us know what kind of configuration (invitation mails or links, SSO or not) you would like to have.

Adding user accounts manually still has its place, too. For example, if you need to add an account that a service can use to access 42Crunch Platform, you must do that manually, because there is no recipient to complete the account creation. User accounts for the auditor role must always be added manually, they cannot be invited to join.


Users in an organization are grouped into teams that have access to API collections shared with them. By default, each organization always has a team that includes everyone in that organization, and more teams can be added as needed for specific groups of users.

Teams are not available in the free community organization.

For these additional teams, there are two ways how to manage them:

  • By default, organization administrators are the ones creating and managing teams in their organization. Once they have created a team, they can assign a team leader for it, who can then add or remove more users to it as needed, but cannot change the name of the team or the team leader. Team members can view who is in their teams, but cannot edit the team in any way.

    An example screenshot showing a sample team with two users, one of whom is the team leader.

  • Organization administrators can choose to grant regular users a permission to manage teams. In this case, the user with this permission can create new teams and delete existing ones, as well as manage team members — including team leaders — in any team in the organization.

    If you have APIs in 42Crunch Platform that should only be shared on a need-to-know basis and you have set up dedicated teams for sharing these APIs, consider carefully if you want to grant the permission to manage teams to any regular users.

In both cases, organization administrators always have full control over all teams in their organization and their composition.

Sharing APIs to teams

In addition to sharing API collections with individual users, collections can also be shared with whole teams at one go. When you share an API collection, you can choose which team or users you want to share it with. You can also give different access rights to your collection for different groups, or even to different users in a team.

The screenshot shows the sharing of an API collection. The collection has been shared with one team and two individual users, with different access levels. The team has been granted read-only rights, except one team member who can also edit APIs in the collection.

Removing a team from the organization does not delete the user accounts of the team members, but it does remove their access to API collections shared with that specific team.

System preferences

System preferences (organization settings) allow organization administrators to control certain high-level options throughout their organization to change or add to the default settings in 42Crunch Platform. For example:

  • Organization administrators can define a custom message banner that is shown at the top of the platform landing page to all users in their organization. See Add a message banner on the landing page.
  • Organization administrators can switch the RSS feed on the platform landing page on or off. See Manage the RSS feed.
  • Apart from some basic limitations like maximum length and reserved characters, the names for APIs and API collections do not have defined naming conventions. Organizations can specify a regular expression that all APIs imported and API collections created in the organization must follow. The specified naming conventions are applied in addition to the basic limitations already imposed by the platform. See Define a naming convention for APIs and Define a naming convention for API collections

This way you can easily impose restrictions or conventions stricter than the default behavior to suit your organization's needs.

Single sign-on integration for businesses

42Crunch Platform uses OpenID Connect (OIDC) for single sign-on (SSO). Companies on the Enterprise plan can integrate the platform with their SSO solution, and employees of the company log in to the platform using their work emails. Companies can also still create non-SSO accounts when needed, for example, for consultants external to the company.

Self-registering with a work email can be enabled, so that employees can create their accounts themselves, or it can be switched off completely. In this case, employees must either be onboarded or invited to the platform.

When SSO is enabled, employees of the company can login to the platform using their normal corporate credentials, or using 3rd-party login (for example, their GitHub or Google account) if the email is the same as in their corporate credentials. Otherwise, the login will fail.

If you are interested in integrating 42Crunch Platform with your SSO solution, or you would like to change your existing integration with us, contact our support or your 42Crunch account manager.

Platform audit logs

As part of its operation, 42Crunch Platform creates audit logs on the activity in the platform to create an audit trail. The audit logs are separated from other logs and record, for example:

  • What happened?
  • When it happened?
  • Who performed the action?
  • What was the target of the action?

Platform audit logs are generated per organization, and organization administrators can view the activity in their particular organization in platform audit logs. You can see actions in your organization, which user performed which action, and when those happened.

An example screenshot of the platform audit logs tab on the platform administration page.

The authentication type column also gives you an idea where the action originated from:

  • Cookie: These actions were triggered by authenticated users interacting with the platform UI, or from scripts that use cookie for authentication (and not API key).
  • API key: These actions were triggered by API calls, for example, from the integration plugins (like CI/CD or IDE) or from scripts.

Platform audit logs are intended as a diagnostic tool, not a detection tool. The logs are not real-time, there is a delay of one minute before you can see the events when you refresh the log page. Platform audit logs are for gathering information: for example, if you become aware of a compromised API key, you can then use platform audit logs to drill down to the activity in your organization to check if that API key has been used to perform an action and when was the last time it was used. If you click on an event, you can view more details on it, such as the name of the API key that was used, listed in the Session ID field (here token_auth).

Platform audit logs can also be exported as JSON, for example, for reporting purposes.

Platform audit logs are provided on activity over the last three months. For security reasons, regular users cannot view platform audit logs.

Currently, only the events from the last 24 hours are visible on the UI. This will be improved on in a later release.

Platform URL

Platform URL is the URL where you access 42Crunch Platform. For users in most organizations (including the free Community organization) that is However, enterprise customers can get a dedicated platform instance, with its own custom platform URL.

If your organization has a dedicated platform URL and you do not access the platform at, this also has implications to configuring some features:

  • You must replace the default URL with your platform URL in your CI/CD plugins.
  • You must replace the hostname with the hostname of your platform URL (for example, when you configure the following endpoints:
Default endpoint Custom endpoint Description The endpoint used by API Firewall The endpoint used by Conformance Scan when run on-premises

If you are not sure what your platform URL is, contact our support.