What a data source governs
- Provenance — Every record, relationship, and object references its originating source so you can audit lineage and route updates back to the right system of record.
- Synchronization flow — The source declares how data arrives (currently API push) and which environments or jobs publish into it.
- Processing boundary — Validation, ingestion pipelines, and access controls execute independently per source, allowing teams to tune quality gates without affecting other domains.
The Clinia platform currently only supports API-driven synchronization.
Configuration essentials
A data source definition consists of a unique key, metadata, and the profiles it owns. Keep keys stable because they appear in API paths, identifiers, and audit logs.key
— URL-safe identifier referenced across registry APIs and partitions. Must follow this pattern:^[a-zA-Z0-9-][\w-]{0,61}$
type
— Categorizes how data is managed. Useregistry
for resources written directly to the Clinia registry.
The Clinia platform only supports
registry
sources at this time.Operating data sources
- One source per schema — When upstream systems expose different schemas or lifecycle rules, create dedicated sources. This keeps validation strict and provenance clear.
- Coordinate schema changes — Version profiles before pushing breaking changes so ingestion never fails unexpectedly.
- Secure access — Tie API keys and IAM roles to specific sources to prevent accidental cross-domain writes.
- Monitor freshness — Track ingestion timestamps to surface sources that stopped publishing data.
Related references
- List the data sources API for the canonical schema and endpoints.
- Data ingestion overview to understand how sources feed the registry.