Marketplace

The catalogue is what members see: one product per card, authored entirely through this API. Access requests are what comes back: one row per member per product, which an admin approves or denies. For a scanner product the approval is the entitlement — approving grants the indicator on TradingView.

The public routes are mounted with optional auth, which only reads a Bearer JWT — it does not honour the gateway's internal service key. An admin flag on a public route would therefore fail for the dashboard even though its writes succeed. That is why the admin catalogue is GET /products/all and not GET /products?includeInactive=true. The flag form looks like it works: it returns 200 with the active products and silently drops every deactivated one.

Its indicator is granted by approving a request, and a link takes none — so the card would look configured and grant nothing, forever. POST and PUT both reject the combination with 400.

productType defaults to misc and ctaType reads back as form on rows created before either field existed, which is exactly what those products are. Read both defensively on the client — older rows may omit ctaType, ctaUrl and requestFields entirely.

Omit requestFields and the product's form is left exactly as it was — a rename or a sort-order nudge must not wipe a form. Send [] and the form is cleared. Send an array and it replaces the form wholesale; there is no per-field patch.

Each submitted answer snapshots the question's label at the time it was asked. Renaming a field later changes what new members are asked; it does not change what an existing request shows a reviewer.

Deleting removes the card outright. Access requests that pointed at it stay in the queue with a productId that no longer resolves, and a reviewer loses the context for a decision they still have to make. Setting isActive: false takes the card off the marketplace and keeps every request readable.

An indicator that a marketplace product still points at cannot itself be deleted — see Delete Indicator.

• Send no auth headers. The signature is the authorisation; an X-API-Key or Authorization header on this request is not expected by S3.
• Use the same Content-Type you asked for. A different one does not match what was signed and S3 rejects it.
• The URL expires in 15 minutes (expiresIn, in seconds). Ask for a fresh one rather than retrying an expired signature.

A failure at this step is usually the bucket's CORS policy not allowing PUT from the calling origin.

The bucket is written with a one-year Cache-Control, so reusing a key per product would leave the old picture on the card long after it was replaced. Replacing an image always produces a new URL — update imageUrl to match.

• At most 25 custom fields per product.
• Every field needs a non-empty label.
• A key must contain at least one letter or digit after normalising.
• Two fields must not normalise to the same key — rename one.
• A select needs at least one option.
• These keys are already collected on every request and are refused: productid, fullname, full_name, email, tradingviewid, tradingview_id, status, responses.

A malformed form is refused when it is built rather than repaired — otherwise the failure surfaces as a rejected submission from a member who did nothing wrong.

tradingviewId is what an approval is eventually delivered with, so a scanner request is rejected with 400 without one. Accepting it would move the failure to the moment an admin clicks Approve, where it reads as the approval breaking rather than the form being incomplete. misc products carry no entitlement and leave the field optional.

POST for a product whose ctaType is link returns 400 — 1hstream renders a hyperlink for those and never reaches here. A request that arrived anyway would sit in the queue as something an admin can approve to no effect.

Requests taken before the form settled may carry a phone or message. Both are still returned so a reviewer can read them, but neither is collected or accepted any more.

• Approving creates — or revives — the access row and queues the TradingView grant, with source: "marketplace" and the request id recorded on it.
• Withdrawing an approval (to denied or pending) queues the revoke, and only for the row this request created. A separate manual grant to the same person survives.
• Nothing happens when the status is unchanged, and nothing happens at all for a misc product.

See Per-Indicator Access for what the grant does next.

If the TradingView call cannot be made, the decision is still saved and the response carries an entitlementWarning alongside the request. The grant lands in failed and appears on the failures worklist. Surface the warning rather than treating the call as a plain success — the HTTP status is still 200.

An approval for a request with no tradingviewId on record produces the same warning and no grant: "Approved, but this request has no TradingView username — grant it manually from the Scanners page once you have one."

401 and 403 are raised by the role middleware before the handler runs, and come back as { "error": { "code": "FORBIDDEN", "message": "Insufficient permissions" } } — no success, no meta. Parse defensively rather than assuming the envelope above.