The EVRYTHNG Platform allows developers to make their products smarter by connecting them to the web and giving them their own unique online Active Digital Identity (or ADI). We call all these ADI-enabled products connected to the web ‘Thngs’. Each Thng is a permanent cloud data resource that holds up-to-date information about the corresponding real-world product or device. The attributes and state of a real-world product is reflected in the Thng, which in turn can be connected to countless other platforms and integrations to drive rich experiences.
A Thng is just one of many types of resource available on the EVRYTHNG Platform. These resources are created, owned, and managed by one of several types of actors, representing different kinds of users. Actors have their own roles and permissions for customisable access rights and visibility, and make requests to the Platform with their own unique API keys. Visibility and grouping of resources is also specified with various levels of scope, allowing precise access control and separation of concerns for multiple client projects.
The rest of this page outlines other important resource types and concepts. Read the linked documentation sections for all the finer details and extra information.
Each EVRYTHNG Platform integration begins with an account, created when a developer signs up for the EVRYTHNG Dashboard. Management of account-level resources and other setup is done by the account owner as the ‘Operator’ actor. Operators can configure virtually all resources and relationships in an account, with the highest levels of access with their Operator API Key, or through the Dashboard.
Accounts can also be shared between two or more Operators with separate Dashboard accounts, and given specific roles to allow controlled data access when sharing resources with collaborators. These roles can limit a guest Operator’s visibility to certain projects or Dashboard pages as required.
Project resources are the primary method of limiting visibility of other types of resource through the project scope, and allow developers to implement a logical separation of resources to reflect their real-world grouping. For example, a project may contain all Thngs that belong to a single marketing campaign, and also limit visibility to only other Operators that worked on that campaign. The majority of sub-account level resource types support scoping to one or more projects as required by the integration designer, except those that are designed to be accessible or affect the entire account.
Each project may contain one or more application resources which represent end-user web or mobile applications providing views and control over the resources contained in an account. For example, a warehouse manager may use a custom-made mobile app (represented as an EVRYTHNG application resource) that shows all stock in his warehouse, and allow him to mark them as received/shipped/missing as part of his job. These applications use their Application API Key to create and authenticate Application Users (see below) who interact with resources they own and control.
Application User resources represent the people interacting with the EVRYTHNG Platform integration as part of their role within the solution, such as the previously given warehouse manager example. Application Users are created with an email address and password login, plus their name, birthday, and other details that can be used for user management and insights. Application Users are scoped to the application resource that created them, limiting access to those resources in the application’s project scope. This can be customised by changing resource scopes as well as creating and assigning Application User roles and permissions.
Upon creation (as well as each subsequent login) an Application User is granted their own Application User API Key that is their access credential to interact with the resources that the account Operator has made available and in-scope to them.
The core data containing resources of the EVRYTHNG Platform are Thngs. Each product connected to the Platform is represented by a Thng resources. To facilitate their roles as digital product counterparts, Thngs can store data as key-value pairs of JSON data as single value
identifiers (SKU-level data), or as
properties (real-time state) that have a history of previous values available.
Thngs can (and should) maintain a reference to their SKU in the form of a product resource. A product resource is designed to act as a class containing data and information that is common to all Thng instances. For example, a set of Thngs each representing individual soda cans should reference the single product resource that specifies the product barcode, serial number, color codes, and other common items of data.
The third main resource type is the collection resource. A collection is designed to enable grouping of Thngs (and even other collections) into a single referrable resource, and usually represents a batch pallet of manufactured goods, a group of devices in the home, and other such groupings. Like Thngs and products, collections can also contain
tags to facilitate common data and labelling for organisation purposes.
As opposed to data container resources (Thngs, products, etc.), action resources can represent discrete events, messages, and other interactions by Application Users, devices, or other actors. Though not specifically designed as a mutable data container resource, actions can also include
tags, to enhance their capabilities as a record of events.
Actions have an action type associated in a similar relationship as product resources are to Thngs, and are always created on a target Thng, product, or collection as the interaction semantics require. For example, an action could be created on a Thng to signify that is has been sold to a consumer, or on a collection to record it has moved to a new warehouse.
By strategically creating actions of different types on different product resources, data becomes available to drive customisable Dashboard widgets that can provide insight into how the integration is performing. For example, number of missing goods or how well users are engaging with products.