The Intelligence API is read-only. Everything it exposes today is a read, and the credential reflects that.
The key
A bei_ token, issued by BoostEcom and stored as a SHA-256 hash. It
carries the scope read:intelligence.
That scope is enforced. It is worth saying because it was not always: the column was stored, parsed into the caller, and checked nowhere, so the field advertised least privilege and enforced none. It was turned on while every issued key still held exactly that one scope, which was the only moment where enforcing it locked nobody out.
curl https://boostecom.app/api/intelligence/top \
-H "Authorization: Bearer bei_<hex>"
Anything other than a bare Bearer bei_<hex> is refused, not quietly
downgraded to the anonymous tier.
Two tiers
| Tier | Credential | Ceiling counted by |
|---|---|---|
| anonymous | none | IP address |
| key | bei_ | the key |
Counting per key rather than per IP is the practical reason to hold one: if you call from a serverless platform, your address changes between invocations and an IP-counted ceiling is unusable.
Why anonymous passes the scope check
An anonymous caller always satisfies read:intelligence, and that is
deliberate rather than a hole. A scope constrains what a credential may
do. It does not grant anything. These endpoints are public by product
decision, so an anonymous caller's permission comes from the route being
open, not from a token.
A caller that did present a key is bound by what that key says.
Public surfaces
Several intelligence surfaces are public HTML and indexable:
/intelligence/inspect— single-probe inspectors (theme, apps, ads, emails)./intelligence/radar— the radar./intelligence/transparency— method and provenance.
Individual records at /intelligence/<category>/<slug> are
noindex, nofollow and excluded from the sitemap. They stay
reachable for direct links and for MCP clients, but they are not a
crawlable corpus — a deliberate decision, since they describe third-party
stores.
Outbound links from a record to the store it describes are clean URLs
with no UTM parameters and rel="nofollow".
How we identify ourselves
When BoostEcom reads a third-party storefront, the request carries the
user agent BoostEcom-Scanner/1.0, which cites
/about/scanner — the bot policy page a site owner will
find in their logs. That page states what we read and how to opt out.
What no key unlocks
Three families of field are not behind a paywall or a scope: they simply do not exist, and no key produces them:
- Time — how long a store has been doing something.
- Volume — absolute order or revenue counts for a store we do not own.
- The store itself: anything only its owner can see.
If a field is absent from a response, that is the reason. It is not a tier limitation.