Users and Service Accounts

In the Clinia platform, there exists two types of identities to manage access: Users and Service Accounts. While both are part of our Identity and Access Management (IAM) system, they serve different purposes.

• Users represent real people—like team members or administrators—who log into the platform and use our UI interface to manage data, configure settings, or monitor activity.
• Service Accounts, on the other hand, represent automated systems or applications. They’re used when a program or script needs to connect to our API to send or retrieve data behind the scenes, without using our UI interface.

By separating human and machine access, we can assign the right level of control to each, keep your system secure, and give you the flexibility to automate workflows where needed.

This table summarizes the differences between both Users and Service Accounts

Users Account

Users are real people who interact with the system via the Administration Portal. They typically include internal team members, collaborators, or administrators who need a user interface to manage records, service accounts or other users.

Each user is authenticated through Clinia's identity provider and can be assigned a single role, which defines what they can do on the platform.

Service Accounts (Machine Users)

Key traits of service accounts:

• They can not log into any UI interface
• They authenticate via API credentials (see API Authentication)
• They are also assigned exactly one role, just like users

Example use cases:

• A data pipeline that syncs new and existing records into a data source daily
• A third-party service that queries partition data through the API

API Credentials

API Credentials (commonly known as API keys) are secure tokens used to authenticate requests made directly to our API. They allow both users and service accounts to make authenticated API calls to Clinia’s endpoints on their behalf. Each credential is tied to a specific identity (either a user or a service account) and carries the same role-based and policy-based access controls defined for that identity.

It’s important to note that API credentials are tied to an entity. As such, if the role for that entity is modified or the entity itself is deactivated, then the API credentials will also be affected.