Access Control (v2)

The EVRYTHNG Platform includes several mechanism that allow configuration of granular access to resources within any given account. These make it possible to allow effective collaboration between team members with different needs and privileges, and also provides the security required where product and user data is concerned.

By default, these features provide an intuitive degree of access that is suitable for most accounts. However, for those that require more strict control of resources for access and security purposes, they are also highly customisable when combined and correctly configured. This page aims to help explain how these mechanisms work, and also how to achieve some of the most common requirements and scenarios.

The following gives a brief summary of each of the access control features available to developers to leverage in their integrations. More in-depth information can be found on the linked pages.

Two Types of Actor - Operators and Access Tokens

Operators and Access Tokens are the two different actors that our platform supports.
Both Operators and Access Tokens can have roles that define their access to the platform. What separates them apart is that an Operator is related to a user - a person that is signed into our platform, whereas an Access Token could represent, for instance, the authorised access for a software used by other systems, or a mobile application used by people that are not signed into the EVRYTHNG platform.

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

API Keys

Both Operators and Access Tokens have an API key directly related to them. For example, each Operator collaborating as team members on a given EVRYTHNG account will have an Operator API Key that is unique per user, per account. Similarly, a given Access Token signed into our platform and part of a certain account will have an API Key that is unique per per account.

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

Roles and Permissions

Any given API key has at least one role that defines what that actor is reasonably required to do. By making use of the platform roles and assigning them to a given Operator, one could, for example, be able to read products and thngs, but not update or delete them.
Similarly, an Access Token could have a role that would only be allowed to read some specific resources and create specific actions.

See Roles and Permissions for more information about roles.

Restrictive conditions

Beyond roles - that define what resources actors can access and the operations they can make on those resources - it is also possible to restrict access based on attribute filtering.

For example, a sourcing manager that is responsible for 10 different factories may only need access to data that is relevant to those factories. Moreover, factory administrators may only need access to data that is produced on their factories.

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

Read the Restrictive Conditions page to learn more information on how to restrict access using attribute filtering.

Getting "my own" current access

To retrieve their own access details for a given account, operators can reach the /me API using their access API key. This is available for almost all roles for any Operators with a valid API key and will return the current Operator access details, including their restrictions and detailed roles.

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

Go to the Operator Access page to learn more information on how to obtain the current Operator access details at any point in time.

Updated 2 months ago

Access Control (v2)

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.