Changelog

This is the public record of what changed in the neolife API, newest first. New behavior is additive by default; anything that could break an existing integration is announced ahead of time and shipped behind a dated version.

How this changelog works#

• Dated entries, newest first. Each entry is stamped with the month it went live and lists what became available.
• Additive by default. New endpoints, fields, and optional parameters ship without a version bump. Adding a field to a response is not a breaking change — build clients that ignore unknown fields.
• Breaking changes are announced and versioned. A change that removes a field, changes a type, or alters existing behavior is published here first, then made available behind a dated version prefix. Pin the dated /v1/* prefix so a future version never moves under you. See Versioning.
• Every response is self-describing. A Neolife-Version header tells you exactly which version answered a request, so you can confirm what you're talking to.

2026-07 — Initial release#

The first generally available surface of the neolife fulfillment rail. Everything below is stable and covered by the versioning policy above.

Orders. Create, approve, submit, and track fulfillment orders. Submission requires provider approval — the API refuses to submit an order that a licensed provider hasn't approved. See Orders and the Orders API.

Intake. Compliance questionnaires and provider approval as first-class resources, so a patient's clinical intake and its approval are captured before any order is eligible to ship. See Intake and the Intake API.

Routing and failover. Orders route to a connected compounding pharmacy, with automatic failover to a backup connection when one is unavailable. See Routing and the Pharmacies API.

Idempotency. Every mutation accepts an Idempotency-Key (a UUID) and acts at most once — a retry never ships twice. See Idempotency.

PHI-free webhooks and events. Fulfillment status flows back over webhooks and a durable, replayable event log carrying only ids and status — no patient data — so your callback endpoint stays out of PHI scope. See The PHI boundary, the Webhooks API, and the Events API.

Machine API keys. Server-side keys with nk_live_… and nk_sandbox_… prefixes, managed over the Keys API. Sandbox resolves only to synthetic patients so you can build the full integration before an agreement is in place. See Authentication and Sandbox.

SDKs. Official Node/TypeScript and Python SDKs, with idempotency-key derivation built in.

CLI. A command-line tool for keys, orders, and events from your terminal and CI.

MCP server. An MCP server that exposes the rail to AI agents and assistants.

Next steps#

• Versioning — how versions are dated, pinned, and deprecated.
• Glossary — the terms used across these docs.