Consentrix separates customer identity, internal user access, and system-to-system authentication so audit and organization scope stay clear. This is especially important for a consent platform, where identity boundaries and data minimization directly affect privacy and compliance posture.
Identity Types
| Identity | Used for | Example |
|---|
| customer_id | Your organization's external customer reference | cust_12345 |
| Subject | Consentrix internal record linked to one customer_id | 550e8400-e29b-41d4-a716-446655440000 |
| User | Human operator in the Backoffice | ops@company.com |
| Role & Permission | Access rules for Backoffice users | users:view, consent_templates:approve |
| System / API Key | Machine-to-machine authentication | checkout-service |
| Alias | Organization identifier in the platform | acme-corp |
Subject vs customer_id
These are related, but they are not the same thing:
| Item | Owned by | Purpose | Where it appears |
|---|
customer_id | Your organization | Stable customer reference from your own systems | Public API paths, search, backoffice lookups |
| Subject | Consentrix | Internal record used to link decisions, products, and controls | Internal records, admin responses, audit-related joins |
- Your application sends
customer_id when calling the API.
- Consentrix resolves that value to an internal Subject record.
- The Subject is created on first use and lets the platform keep consent history and related controls consistent over time.
How They Connect
customer_id is the customer reference that comes from your own systems.- A subject is the internal record Consentrix derives from that
customer_id.
- A user is an internal operator.
- Roles and permissions control what users can do.
- A system and API key are used by applications.
- An alias identifies your organization inside the platform.
Privacy and Data Minimization
Consentrix is designed to keep consent records linkable without becoming a customer profile store.
| Principle | What Consentrix does |
|---|
| Store the minimum needed to link consent | Keeps the customer's external customer_id plus internal technical identifiers such as the Subject record |
| Avoid storing unnecessary PII | Does not treat names, email addresses, phone numbers, or other profile fields as part of the core consent identity model |
| Keep rich profile data in your own systems | Uses your systems or profile APIs when extra customer details are needed for display or lookup flows |
In practice, this means Consentrix stores the customer's customer_id as the main business identifier for consent records, while richer customer profile data stays in your own systems. This is an important property of a consent management platform: it should preserve auditable consent history without becoming the primary repository for customer PII.
Practical Rules
| Rule | Why it matters |
|---|
Do not treat customer_id, Subject, and User as the same thing | They serve different privacy and access purposes |
Send a stable customer_id from your own systems | Consent records depend on it staying consistent |
| Use roles instead of shared accounts | Improves auditability and least-privilege control |
| Use separate systems for separate applications | Makes key rotation and incident response safer |
| Keep PII in your own systems unless there is a clear business need elsewhere | Preserves data minimization |
| Keep the alias aligned with the correct organization | It affects routing and authentication context |
Common Scenarios
| Scenario | What to use |
|---|
| A business user needs portal access | Create a User and assign roles |
| A service needs to call the API | Create a System and generate an API key |
| You need to look up a customer's consent | Start with the customer's customer_id; Consentrix resolves the Subject internally |
| You need to diagnose organization-specific behavior | Check the organization's Alias and access scope |