routing — the money path

A lead arrives. Routing decides which buyers want it, in what order, at what price, and delivers it to them — or does not, and writes down why. It is the only service here where a mistake costs somebody money on the spot, which is why nothing about it is being rushed.

Health — live

not asked

This check runs in your browser and has not run yet. With JavaScript off it never runs, and this line stays as it is — which is the honest answer: nothing was asked, so nothing is known.

This route is open to anybody and carries no Access-Control-Allow-Origin header, so a browser on this origin normally cannot read the answer even though the request succeeds. That is deliberate — the route exists for the deploy's health-checked auto-revert and for monitoring — and it is why the badge above usually says answered, unreadable here rather than up. The curl below is not bound by the same-origin policy and shows what it actually returns.

This hostname serves exactly one route, and that is the finding

$ for p in /api/routing/health /api/v1/lead /api/demand /api/v1/delivery-count /; do
    printf '%-24s ' "$p"
    curl -s -o /dev/null -w '%{http_code}\n' "https://routing.lrs.amtechhq.com$p"
  done
/api/routing/health      200
/api/v1/lead             404
/api/demand              404
/api/v1/delivery-count   404
/                        404

Recorded 2026-09-06. Every path but the health check is a 404 from the public internet, and that is not a broken deployment. The routing binary on port 8103 is a health route and nothing else. The lead path lives in two other binaries in the same repository — leadsvc, which does the work, and leadgate, which sits in front of it — and neither is published under this hostname. Real lead traffic arrives at api.leadsaleshub.com.

Nothing on this site posts a lead. The lead intake route is POST /{sellerKey} on the live system, in front of real buyers and real money. A demonstration that put a fake lead into it would be putting a fake lead into somebody's business. So this page describes the path and does not exercise it — which is the same rule the fraud page follows in the opposite direction: fraud has a boundary built to be called by strangers, and it is called.

The cutover, which is the interesting part

leadgate is a Go reverse proxy sitting in front of 100% of lead traffic, routing per seller campaign key from a file on disk. Each campaign is in one of three modes:

Mode	What happens to a lead
passthrough	Straight to the legacy system. The new one never sees it. This is where every campaign is today.
shadow	Both systems process it; the legacy answer is the one returned. The deliverable is the divergence report: what differed, on which field, for which campaign.
live	The new system's answer is the one the seller gets.

Two things about that design are worth stating. A shadow mode that silently preferred one answer would prove nothing — it would be a slower passthrough with a second system warmed up — so the comparison is the product, and which campaign goes live, and when, is an operator decision made with that report in hand. And the granularity is deliberate: a mistake costs one campaign rather than all lead traffic. Rollback is systemctl reload leadgate.

Status, from platform/docs/ROADMAP.md: ported and deployed since 2026-08-30, wired into real traffic in passthrough mode, sweep timer running, no campaign live. Passthrough is transparent, but it is still a new dependency in front of live lead intake, and the roadmap says so rather than calling it zero-risk.

The receipt

Every distribution writes an immutable record of what the configuration said at the moment of the sale — which buyers were eligible, in what order, at what price. That receipt is what makes it safe to defer billing entirely: there are no invoice or return tables in any new schema, and there do not need to be, because the facts an invoice would be computed from are already written down and cannot change underneath it.