Glossary

A quick reference for the vocabulary this documentation uses. Each term links to the page where it's explained in full.

Domain terms#

Order — the unit of fulfillment: one approved request to fill and ship product to a patient. An order moves through a lifecycle (pending_approval → approved → submitting → submitted → tracked) and is only eligible for submission once a licensed provider has approved it. See Orders & fulfillment.

Intake — the compliance questionnaire a patient completes before an order can proceed. A deterministic rule set produces a verdict (eligible / ineligible), and an eligible submission is issued a certificate. Available as an authenticated API and as a drop-in public embed widget. See Intake & provider approval.

Provider approval — the mandatory clinical gate: a licensed provider reviews an eligible intake and approves (or rejects) it. No order — first-time or refill — can be submitted to a pharmacy until it is provider-approved. The API refuses to submit an unapproved order. See Intake & provider approval.

Certificate — a tamper-evident, PHI-free record binding a questionnaire key + version, the answers, the verdict, and a timestamp under a single hash. It's durable proof that this patient cleared this version of the deterministic gate — a hash and version pins, no names or answers, so it travels safely through logs and events. See Intake & provider approval.

Pharmacy connection — a configured, routable link to a compounding pharmacy (conn_…). Each connection is a destination an order line can be routed to; you can add, swap, or add a backup connection without touching your integration. See Pharmacies.

Routing policy — the per-tenant rule that decides which pharmacy connection each order line goes to (for example per_product), plus whether failover is enabled. One approved order, routed to the right pharmacy by policy. See Cross-pharmacy routing & failover.

Failover — single-hop, automatic recovery: if a pharmacy rejects a submitted child order, failover moves that line to an alternate connection so it can resubmit — retry once, never twice — instead of stranding the patient's order. Governed by your routing policy's failover setting. See Cross-pharmacy routing & failover.

Single dispatch — the server-side safety lock that guarantees an order is dispatched to a pharmacy at most once. When submission is claimed, the order enters a submitting state; combined with idempotency, this is what lets you retry aggressively without ever double-shipping. See Orders & fulfillment.

Idempotency key — a UUID you send in the Idempotency-Key header on any mutation. A given key acts at most once: a retry with the same key and body replays the stored response instead of re-running. UUID-only, so no patient data can ever be encoded in a key. See Idempotency.

PHI boundary — the line that keeps protected health information out of your callback and log surfaces. Events, webhooks, certificates, and idempotency keys carry only ids and status; you hydrate patient and order detail over authenticated GETs when you need it. This keeps your webhook endpoint outside PHI scope. See The PHI boundary.

Event — a durable, PHI-free record of something that happened on the rail (for example intake.certificate.issued, order.submitted), carrying ids and status only. Events are stored, pullable, and replayable from the event log. See Events.

Webhook — a push delivery of an event to an HTTPS endpoint you register. Same PHI-free payload as the event log; webhooks are the push side and the event log is the durable pull side of the same reconciliation model. See Webhooks.

Subscription / refill — a subscription arms a refill schedule with a cadence (intervalDays) and a nextFillAt; on each cycle neolife drafts the next order automatically. A refill is a new order created in pending_approval — it automates the logistics of reordering, never the clinical decision, so every refill is provider-reviewed before it can ship. See Subscriptions & refills.

Machine API key — a server-side secret used as a bearer token (Authorization: Bearer nk_live_… or nk_sandbox_…). nk_sandbox_… keys resolve to synthetic patients and a mock pharmacy; nk_live_… keys act on real patients. Keep keys server-side — never ship them in a browser or mobile app. See Authentication.

Sandbox vs. live — sandbox (nk_sandbox_…) is a fully-functional environment that resolves only to synthetic patients, so you can build the whole integration before any agreement is in place; live (nk_live_…) acts on real patients and requires an active agreement. Same API surface, different key. See Sandbox.

Embed key — a per-tenant, origin-locked key used by the public intake widget instead of your secret API key. It returns a patient-safe response — verdict and certificate only — so the questionnaire can run directly on your storefront without exposing your machine key. See Intake & provider approval.

MCP (Model Context Protocol) — the protocol behind neolife's first-class MCP server, which lets an AI agent read and act on the rail through the same guarded surface as every other client. Provider approval, idempotency, and the PHI boundary all hold identically for agents. See MCP (AI agents).

See also#

• Orders & fulfillment — the order lifecycle end to end.
• The PHI boundary — what does and doesn't cross the line.
• Errors — the stable error codes you'll handle.