marketplace — the parties and the contracts between them

Marketplace holds the two sides of the trade and the paperwork between them: the buyers and sellers, what each buyer wants, what they will pay, where to send it and in what shape. When routing sells a lead, every fact it used to decide came from here.

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.

Verify it yourself — recorded 2026-09-06

$ curl -s https://marketplace.lrs.amtechhq.com/api/marketplace/health
{"service":"marketplace","status":"ok"}

$ curl -s https://marketplace.lrs.amtechhq.com/api/v1/fields
{"success":false,"errors":["an Authorization: Bearer <api_key> header is required"],
 "meta":{"timestamp":"2026-09-06T18:06:13Z"}}
# HTTP 401

The field dictionary behind that refusal is 242 rows, and it is one of only three things in the whole platform allowed to carry over from the legacy system. The rule is fresh start: new schemas begin empty and lead, transaction, delivery and session history never migrates. The three exceptions all exist to keep an external contract intact — the field dictionary, the seller campaign keys, and the SMS opt-out state. A person who has opted out has opted out, and starting fresh must not un-opt them.

What it holds

Parties — a buyer or a seller, with roles and channels.
Buyer offers — what somebody will buy, with filters saying which leads qualify.
Endpoints — where a sold lead is delivered, and in what format.
Contracts — the terms, and an assessment of them.
The field dictionary — the 242 field keys every service spells the same way.

Two decisions worth knowing before touching it

One template syntax

A delivery payload is a template with %%FIELD_KEY%% placeholders, rendered by one function that both the endpoint tester and production delivery call — so what an operator sees when they press test is produced by the code that will do the delivering, not by a second renderer that could disagree with it. There is a read-time shim for the older {{FIELD}} spelling and a mandatory sweep for placeholders that did not resolve, because a payload delivered with %%EMAIL%% still in it is a payload the buyer will reject and nobody will notice until they do.

A buyer endpoint credential is replayable, and is stored in plaintext on purpose

An ADR was written specifically to say this out loud rather than let somebody discover it. A buyer's endpoint credential has to be sent to the buyer, as the buyer specified it, on every delivery. It cannot be hashed, because a hash cannot be replayed, and delivery is replay. Writing it down as a decision is what stops somebody "fixing" it later and breaking every delivery in the estate.

Why marketplace and fraud cannot see each other. The seller campaign key on the fraud page is example-site. Fraud records that key and cannot verify it, because verifying it would mean reading marketplace's seller_campaigns table, and no fraud database user holds any privilege on marketplace's schema — not even REFERENCES, so a cross-schema foreign key cannot be created either. The join that would answer which seller owns this campaign? is re-entered in fraud as its own configuration, through its own API. That is the cost of the isolation, paid deliberately.