Changelog

What shipped, when.

Every Signal release, dated and described. Breaking changes are flagged a version ahead.

Get an API key Browse templates

Display mode never touches PHI — no BAA required. Start in 5 minutes.

One template, over time Today released v1.3

v1.0 v1.1 v1.2 v1.3

Mid-arc patient keeps their version New stream ships the latest

Stream versioning

Templates evolve. Patients mid-arc stay safe.

A stream is bound to one template at create-time, but templates are not frozen. Federal guidance changes; a buyer requests a tone shift; a message gets retired. Three migration strategies cover the realistic cases. The choice depends on whether the change is safe for patients already mid-arc.

Strategy 1

In-place

For changes that are safe mid-arc: a typo fix, a clearer phrasing, a less-clinical word swap. The message is updated; all streams (new and in-flight) pick up the new text on the next cue. No new template version; no patient migration. Use when the semantic content is unchanged.

Strategy 2

Drain

For changes that should not reach patients mid-arc: a retired federal source, a clinical recommendation update, a tone shift mid-template. A new template version (template_id_v2) is created. New streams open against v2; existing streams complete their arc on v1 then close. Drain time = the longest active stream's remaining days.

Strategy 3

Forklift

For changes that should reach all patients including those mid-arc: a safety advisory, a recall, an audience-tag schema change. Existing streams are migrated to a new template_id at the next cue. Patient day counter preserved; the rest of the arc switches to the new template's messages. Used rarely; requires explicit partner consent.

How partners are notified

Every template version change writes an entry to the partner's audit log and (for Deliver mode) fires a stream.version_changed webhook with old_template_id, new_template_id, strategy, and effective_at. Drain strategies fire the webhook on create; forklift strategies fire on each affected stream's first post-migration cue.

§2 · Template version log

Every template version, every migration mode.

Each template-version change writes one row in the partner-facing log. Columns: date · template · old version → new version · migration mode (in-place / drain / forklift) · effective_at · notes. Below are the initial-launch entries; subsequent updates land here as templates iterate.

Initial-launch state

Signal is pre-customer; these are the v0/v1 catalog-ship entries from 2026-05-23. Subsequent template-version migrations append here as they actually run.

Date	Template	Version	Migration mode	Notes
2026-05-23	General Wellness	v1 (initial)	INITIAL	Daily · indefinite. CDC/NIH/USPSTF-sourced. Catalog ship.
2026-05-23	Relapse Prevention	v1 (initial)	INITIAL	90-day arc. SAMHSA-sourced. Catalog ship.
2026-05-23	Diabetes · Pharma Init	v1 (initial)	INITIAL	30-day arc. NIDDK + ADA-sourced. Catalog ship.

What the mode badge will look like in production

When a template version actually migrates (after the first production customer), the mode column shows IN-PLACE (cosmetic / clarity), DRAIN (existing streams finish on v1, new streams start v2), or FORKLIFT (existing streams migrate mid-arc, used rarely + with explicit partner consent — see §1).

The log shown here covers the 3 Live templates. The 4 Next templates + 4 Soon templates land here when they activate; status changes (Next → Live, Soon → Next) append to the log just like version changes.

§3 · API changelog

Every endpoint change, versioned + audit-logged.

The /v1/signal/streams API surface is the partner contract. Changes follow the same 3-mode migration model as templates: cosmetic changes update the docs only; semantic changes ship as a new minor (v1.1, v1.2, …); breaking changes ship as a new major (v2) with a drain period.

Launch baseline + additive changes

v1 of the /v1/signal/streams surface (5 endpoints) + v0.1 of the MCP server (4 tools) launched 2026-05-23. Additive changes since — a new optional header, standard rate-limit headers, a forward-compatible response vocabulary — carry their ship date and an ADDITIVE badge; none break a tolerant integration. Semantic changes would ship as a new minor, breaking changes as a new major with a drain period.

Date	Endpoint	Version	Change	Notes
2026-05-23	`POST /v1/signal/streams`	v1 (initial)	INITIAL	Create a new stream. Body: template_id + mode + patient_ref + audience tags (this call enrolls the member).
2026-05-23	`GET /v1/signal/streams/:id`	v1 (initial)	INITIAL	Read stream state + the current cue. Idempotent, safe to poll.
2026-05-23	`POST /v1/signal/streams/:id/cue`	v1 (initial)	INITIAL	The repeating loop. Returns message + safety + receptivity.
2026-05-23	`GET /v1/signal/sandbox-topics`	v1 (initial)	INITIAL	Browse the curated subset a stream draws from.
2026-05-23	`mcp.uphealth.us`	v0.1 (initial)	INITIAL	MCP server live. 4 tools wrapping the REST surface.
2026-06-14	`POST /v1/signal/streams`	v1	ADDITIVE	Optional Idempotency-Key request header — a retried create replays the original stream instead of opening a duplicate.
2026-06-14	All /v1 responses	v1	ADDITIVE	RateLimit-Limit / -Remaining / -Reset headers on Discovery-tier responses (where the cue cap applies), plus an X-Request-Id on every response — for client-side backoff and support correlation.
2026-06-15	`POST /v1/signal/streams/:id/cue`	v1	ADDITIVE	Forward-compatible response_action — a well-formed but unrecognized value is accepted and echoed back as normalized_action; only a malformed value is rejected.

§4 · Webhook changelog

Webhook events, contract-logged.

Webhook events fire in Deliver mode (Display mode skips the webhook step — the partner's own delivery channel reports engagement on its own). Each event carries a stable payload contract; additions never break the existing fields.

Initial-launch state

Four event types ship in the v1 webhook surface. Payload additions are forward-compatible; consumers should ignore unknown fields. Schema changes that drop or rename fields trigger a versioned webhook surface (drain model — see §1).

Date	Event	Mode	Change	Notes
2026-05-23	`stream.message_sent`	Deliver only	INITIAL	Fires when Uphealth + Reach send a cue message. Payload: stream_id + message_id + sent_at + channel.
2026-05-23	`stream.engagement`	Deliver only	INITIAL	Fires on open / reply / opt-out. Payload: stream_id + message_id + event_type + occurred_at.
2026-05-23	`stream.version_changed`	Both modes	INITIAL	Fires on template version migration (drain on create; forklift on each affected stream's first post-migration cue). Payload: stream_id + old_template_id + new_template_id + strategy + effective_at.
2026-05-23	`stream.closed`	Both modes	INITIAL	Fires on close call. Payload: stream_id + reason + closed_at + final_day.

Subscribe model

One webhook URL per partner account (configured at /signup or via /talk-to-sales for Deliver mode). All 4 event types fire on the same URL; partners filter by event_type in their handler. URL verification + the signature header (HMAC-SHA256 of the body + your webhook_secret) are configured at Deliver onboarding and ship with every event.

§5 · Developer surface

The surface around the API, shipped and listed.

Beyond the REST contract: the official SDKs, the hosted MCP server and how it has grown, and where Signal is published for agents to discover. Everything here is additive — it adds ways to reach the same v1 API and changes nothing about the contract above.

Date	Area	Change
2026-06-14	Official SDKs	The TypeScript and Python SDKs published — install and run the create plus cue loop in a few lines. See the SDK guide.
2026-06-14	MCP server	A machine-readable output schema on every tool, and the tool's accepted feedback actions single-sourced from the API so the two can never drift.
2026-06-14	MCP registry	Published to the official Model Context Protocol registry as `us.uphealth/mcp` so MCP-aware clients can discover the hosted server.
2026-06-15	MCP server	Request parity with REST — the create tool forwards an idempotency key, and rate-limit headroom is surfaced on each result. Added read-only catalog and OpenAPI resources, two workflow prompts, and widened stream creation to all seven live templates. See the MCP tools reference.
2026-06-15	MCP server	Added the keyless `lookup_health_fact` tool — no key, one already-public federal fact per question, wrapping the public `GET /v1/public/health-fact` endpoint. The MCP server now exposes five tools. See the MCP tools reference.
2026-06-15	Catalogs	Listed in third-party MCP catalogs (Glama, Smithery) so agent builders can discover Signal where they already browse.

Additive by contract

None of these change the v1 API. The SDKs, the MCP server, and the registry plus catalog listings are all additional front doors to the same cued-stream surface documented above. How the API itself evolves — additive by default, breaking changes versioned, retirements announced with a Sunset header — is in the versioning policy.