Access Control

The EVRYTHNG Platform includes several features to configure granular access to resources within an account. These make it possible to allow effective collaboration between team members with different needs and privileges. They also provide the security required where product and user data is concerned.

By default, these features provide a level of access that's suitable for most accounts. For those who require more strict control of resources, the access control features are highly customizable. This page explains how these features work and how to achieve some of the most common requirements and scenarios.

The following section summarizes each of the access control features available to developers to leverage in their integrations. You can find more in-depth information on the linked pages.

Two Types of Actors - Operators and Access Tokens

Operators and Access Tokens are the two types of actors that our platform supports.

Both Operators and Access Tokens can have roles that define their access to the platform. The difference is that an Operator is related to a user—a person who is signed into our platform. An Access Token could represent, for example, the authorized access for software used by other systems or a mobile application used by people who aren't signed into the EVRYTHNG platform.

See Operators, Operator Access and Access Tokens for more information on these types of actors.

API Keys

Operators and Access Tokens have an API key directly related to them. For example, each Operator collaborating as a team member on an EVRYTHNG account has an Operator API Key that's unique across users and accounts. Similarly, an Access Token signed into our platform and part of an account has an API Key that is unique to that account.

See API Keys and Key Permissions for more information about API keys.

Roles and Permissions

Each API key has at least one role that defines what the actor is required to do. By using the platform roles and assigning them to an Actor, one could, for example, be able to read products and Thngs but not update or delete them.

See Roles and Permissions for more information about roles.

Restrictive Conditions

Beyond roles—which define the resources the actors can access and the operations they can perform on those resources—you can also restrict access based on attribute filtering.

For example, a sourcing manager who is responsible for ten different factories only needs access to data that's relevant to those factories. Additionally, factory administrators only need access to data that's produced in their factories.

As another example, a regional brand manager supervises a group of brands in the North American region. The general account administrator needs to restrict this manager to the group of brands within the North American region so they can't see campaigns ouitside their scope of access.

This level of restriction can be achieved by adding conditions to an actor's access through the Operator Access API if they're Operators, or Access Tokens API if they're services.

Read Restrictive Conditions to learn more about how to restrict access using attribute filtering.

Getting "my own" Current Access

To retrieve their own access details for an account, operators can call the /me API using their access API key. This endpoint is available to any Operator with a valid API key who has permissions to reach it. It returns the current Operator access details, including their restrictions and detailed roles.

Dashboards and Apps that need to perform operations on behalf of Operators can adjust feature restrictions based on the caller's access retrieved through this endpoint.

See Operator Access to learn more about how to get the current Operator access details.