The server half of the ship protocol. The terminal script marks the feature shipped in the ledger; this endpoint renders and sends the requester's notification through the platform sender and records the outcome. It refuses if the feature is not actually marked shipped, and fails closed when its token is not configured rather than running open.
Also called: feature request notification · shipped email · requester notification
- 1POST with the feature code and an optional deep link, authenticated by a dedicated header token.
- 2No token configured returns 503 — the same fail-closed model as the bug-resolution route, never open.
- 3The feature code must match the FEAT-XXXXXX pattern, and the row must exist and be in the shipped state.
- 4Only the requester is emailed, from the platform sender, never through a tenant's own sending pipes.
- 5The deep link resolves in order: an explicit link, the page the request was filed from, then the app root.
- 6What was said and whether it landed are stored on the feature row.
The rule that shapes the email is stated in the notification module: "by ship time the requester has usually forgotten what they asked for (Keith 08-04), so the email quotes their request back, explains how the shipped feature works, says where it lives, and carries an 'Open it in the app' button that lands them directly on it." The split between script and route exists because the script "predates this route and must keep working offline", so it writes the ledger itself and the route does only the part that needs a server.
- Requesters were never told their request had shipped.
- By ship time the requester has forgotten what they asked for.
- A notification route running without a configured token would be open to anyone.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →