La Intelligence API è in sola lettura. Tutto ciò che espone oggi è una lettura, e la credenziale lo riflette.
La chiave
Un token bei_, rilasciato da BoostEcom e memorizzato come hash
SHA-256. Porta lo scope read:intelligence.
Quello scope è applicato. Vale la pena dirlo perché non è sempre stato così: la colonna era memorizzata, analizzata nel chiamante, e verificata da nessuna parte, quindi il campo annunciava il minimo privilegio e non ne applicava nessuno. È stato attivato mentre ogni chiave rilasciata portava ancora esattamente quell'unico scope, l'unico momento in cui applicarlo non ha escluso nessuno.
curl https://boostecom.app/api/intelligence/top \
-H "Authorization: Bearer bei_<hex>"
Qualsiasi cosa diversa da un semplice Bearer bei_<hex> viene
rifiutata, non silenziosamente degradata al livello anonimo.
Due livelli
| Livello | Credenziale | Tetto contato da |
|---|---|---|
| anonimo | nessuna | indirizzo IP |
| chiave | bei_ | la chiave |
Contare per chiave invece che per IP è il motivo pratico per possederne una: se chiami da una piattaforma serverless, il tuo indirizzo cambia tra le invocazioni e un tetto contato per IP è inutilizzabile.
Perché l'anonimo supera la verifica di scope
Un chiamante anonimo soddisfa sempre read:intelligence, ed è
deliberato, non una falla. Uno scope vincola ciò che una
credenziale può fare. Non concede nulla. Questi endpoint sono
pubblici per decisione di prodotto, quindi il permesso di un
chiamante anonimo deriva dal fatto che la route sia aperta, non da un
token.
Un chiamante che ha presentato una chiave è vincolato da ciò che dice quella chiave.
Superfici pubbliche
Diverse superfici di intelligence sono HTML pubblico e indicizzabile:
/intelligence/inspect: ispettori a sonda singola (tema, app, ads, email)./intelligence/radar: il radar./intelligence/transparency: metodo e provenienza.
I singoli record su /intelligence/stores/<dominio> sono
noindex, nofollow ed esclusi dalla sitemap. Restano
raggiungibili per link diretti e per client MCP, ma non sono un
corpus scansionabile: una decisione deliberata, dato che descrivono
store di terze parti.
I link in uscita da un record verso lo store che descrive sono URL
pulite senza parametri UTM e con rel="nofollow".
Come ci identifichiamo
Quando BoostEcom legge uno storefront di terze parti, la richiesta
porta lo user-agent BoostEcom-Scanner/1.0, che cita
/about/scanner: la pagina di policy dei bot che
un proprietario di sito troverà nei suoi log. Quella pagina indica
cosa leggiamo e come effettuare l'opt-out.
Cosa nessuna chiave sblocca
Tre famiglie di campi non sono dietro un paywall né uno scope: semplicemente non esistono, e nessuna chiave le produce:
- Il tempo — da quanto tempo uno store fa qualcosa.
- Il volume — conteggi assoluti di ordini o ricavi per uno store che non possediamo.
- Lo store stesso: qualsiasi cosa solo il suo proprietario può vedere.
Se un campo è assente da una risposta, è questa la ragione. Non è una limitazione di livello.