Indicators

The catalogue is what can be granted — one row per indicator, carrying the TradingView pineId that automation is keyed on. Access is who actually holds each one. Deleting an indicator is a catalogue decision, never a mass revocation, which is why the two are separate.

The product calls them indicators; the API paths and payload fields call them scanners. They refer to the same records — no translation is needed beyond the path.

TradingView is the system of record for who can open an invite-only script, and it knows people only by their TradingView handle. A grant without one cannot be pushed, so every grant endpoint either takes a tradingviewUsername or resolves one from an existing grant or marketplace request.

Like the activity-status webhook, this is a server-to-server call from the external backoffice. It authenticates with the X-Webhook-Secret header alone — no X-API-Key, no JWT — and it is refused outright (503) when no secret is configured on the service.

When granting, the service looks for a handle in three places, in order: the request body, any grant this person already holds, then their most recent marketplace access request. If none of them has one, the request is refused with 422 TRADINGVIEW_USERNAME_REQUIRED and nothing is written — rather than creating a row per indicator that is guaranteed to fail. Retry with tradingview_username once you have it.

A word this endpoint does not recognise returns 400 UNKNOWN_STATUS. Defaulting an unreadable value to "inactive" would revoke paid access for real people, so the failure is deliberately loud.

pineId is TradingView's own identifier for the script — the PUB;<hash> form shown in the invite-only script's URL. An indicator without one can be listed, but never granted automatically.

An indicator anyone still holds, or that a marketplace product still points at, cannot be deleted — the request returns 400 telling you how many. Deactivate it instead (isActive: false), which keeps every access row meaningful and lets an admin revoke deliberately.

Marketplace documents the whole surface — authoring and editing products, the custom request-form builder, product image uploads, and the review queue. What follows is only the part of the funnel that ends in an indicator grant.

This endpoint accepts what the 1hstream marketplace form collects — name, email, TradingView handle — plus answers to any custom questions the product defines, and requires the same fields the form marks required. Nothing else is read from the body.

tradingviewId is what an approval is eventually delivered with, so a request for a scanner product 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.

A second request for the same product and email updates the pending or denied one — that is how somebody corrects a mistyped TradingView handle. A request that has already been approved is returned untouched: its details have been acted on, and rewriting them would desync the grant from the record that produced it.

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.

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