Health Data API: One Contract for Genetics, Biomarkers, Wearables, and Context

Unify workflows while preserving modality differences

A fragmented integration stack can get a demo running, but it pushes normalization, permissions, provenance, trends, and dashboard logic into every application. A unified contract can reduce that work if it does not erase modality-specific constraints.

Build the contract around sources and observations

Evaluate an API by following a real user journey: ingest one available source, create analysis, render a dashboard, retrieve a recommendation or trend, then add a second modality. Ask what happens when a source is stale, a file is malformed, a user requests deletion, or an agent needs only a narrow context query.

Prefer typed, structured responses and published API documentation. Ensure that authorization scopes, organization boundaries, idempotency, webhooks, and lifecycle operations receive the same attention as the headline analysis endpoint.

Five primitives that scale across modalities

Sources represent files, connections, or entered context. Observations represent direct normalized facts. Interpretations add scoped meaning. Analyses combine inputs through a versioned method. Dashboard specifications package outputs for a user experience.

These primitives let products add a second modality without inventing a second identity and authorization system. Each modality can still retain its own quality model and processing path.

Capability discovery for clients

Publish modalities, connection types, supported formats, endpoint IDs, scopes, limits, asynchronous behavior, and current availability through a capability endpoint. Generate OpenAPI and MCP tools from the same schema source where practical.

A client should be able to ask what can be done before collecting personal data. This improves onboarding and lets agents choose a supported path without trial-and-error calls.

• Supported modalities and input formats
• Available providers and connection methods
• Required scopes and endpoint grants
• File, rate, and job limits
• Schema and API versions

Multimodal contract review

• Shared primitives do not erase modality-specific context
• Every output retains source lineage
• Capabilities and limits are discoverable
• REST and MCP expose compatible operations
• Organization isolation is tested
• Export and deletion cover sources and derived outputs

Offer one platform surface for product and agent clients

WellNizz provides one developer surface for genetics, biomarkers, wearables, health context, analyses, trends, action plans, ancestry, provider discovery, dashboards, export/deletion, REST, MCP, and optional x402 access. Provider-specific connectors remain under the hood while public modality names stay stable.

Design consent, export, and deletion into the model

Health data integration involves privacy, security, and sometimes regulation. A well-designed API reduces implementation work but does not transfer your product's legal, clinical, or consent responsibilities.