Digital health compliance, made simple API & Docs |

Object Model follows RESTful approach in defining Resources and their management (creation, access, update, and deletion).

The following object model diagram shows which resources can be managed through the API and how they are interrelated.

Data's API implements a noSql document-oriented database such as MongoDB. We aim at reusing standards and concepts that are familiar to developers, and at solving unpredictable issues without creating lock-ins.


A Repository is used to organize data. Conceptually, it is similar to a DB Schema in SQL jargon. A Repository can belong only to one Customer (account).

show code sample


A Schema describes the Document structure or content (i.e. list of fields). requires an explicit Schema definition to implement content verification and data indexing. By indexing a field, you can run extremely fast search operations over Documents, which will still remain encrypted.

show code sample


A Document contains the actual data in JSON format. Each Document is associated with a Schema. Document fields can be Integer, Float, String, Text, Boolean, Date, Time, DateTime (ISO 8601), JSON, Base64, BLOB. A BLOB field is a link to an attachement (see next div) that can contain any data representation (e.g. XML, HL7 or binary data).

show code sample


BLOB is used to store large binary content such as ECG or X-Ray files. To facilitate BLOB storage and retrieval, each BLOB is assigned to a Document field. In this way, the Document can contain metadata about the actual binary content that you can search and retrieve/download.

The loading of BLOBs is implemented via a chunk-based upload, which makes it easy to upload large files even from low-connectivity devices.

show code sample


A Collection is a way to group documents. A Collection can group documents of different types (having different Schemas). A Collection is used to implement an easy access to a set of documents, e.g. all documents of a specific user.

show code sample


With Users developers can register, authenticate, and manage permissions to Documents and other resources.


Similarly to the Schema for Documents, the UserSchema is used to describe the content (i.e. fields) of a User object. You can use the same set of basic types to define the fields of Document Schema and UserSchema.

show code sample


The User represents the end-user of an app. The User is associated with a UserSchema and stores the defined fields/data. It is used also to implement authentication (OAuth 2.0) and to access control policies (Permissions) to resources (Repositories, Schemas, Documents, UserSchema).

show code sample


A group is used to group a set of users and facilitate the Permissions definition on resources. Users can belong to multiple groups. All Permissions will be evaluated to find at least one that allows a User to perform a requested action.

show code sample


Permissions provide a very granular, yet simple, method to define CRUDA (Create, Read, Update, Delete, Administer) access control policies for Users (or Groups) on a resource (Repositories, Schemas, Documents, UserSchemas).

A Permission is defined on a single resource or on its children (e.g. a user can have updated rights on a Schema or on the Documents related to that Schema).

A Permission has two elements (check code sample):

  • Manage: defines what a User (or Group) can do on a resource (or its children).

  • Authorize: defines which permissions a User (or Group) can transfer to another User (or Group) for a specific resource (or its children).

Check the full API documentation for more examples

show code sample


API calls to must be authenticated with either of these methods:

CustomerId and CustomerKey

These are the access keys that identify the admin of the account and grant unrestricted access to the resources stored in it. Thus, they can be used only in server-to-server communication and must never be written within client-side software (neither in compiled nor non-compiled code - not even encrypted).

Application and Session Tokens

Following the standard OAuth 2.0 protocol, Users can log in via API. Your software is identified with an Application (i.e. by a clientId/clientSecret pair) and your users log in with a username and password of their choice. API return a temporary Access Token which can be used with the Bearer Authentication for making follow-up API calls. Once expired, this token can be renewed with the Refresh Token.

Note that, with API, developers can use OAuth 2.0 protocol in both 2-legged and 3-legged ways to implement both standard client-server authentication and the "OAuth as a Service" mechanism, where is the identity provider for multiple applications that log in.