L'Intelligence API est en lecture seule. Tout ce qu'elle expose aujourd'hui est une lecture, et l'identifiant le reflète.
La clé
Un token bei_, émis par BoostEcom et stocké en hash SHA-256. Il porte
le scope read:intelligence.
Ce scope est appliqué. Ça vaut la peine de le dire parce que ça n'a pas toujours été le cas : la colonne était stockée, analysée dans l'appelant, et vérifiée nulle part, donc le champ annonçait le moindre privilège et n'en appliquait aucun. Il a été activé pendant que chaque clé émise ne portait encore que ce seul scope, le seul moment où l'appliquer n'a bloqué personne.
curl https://boostecom.app/api/intelligence/top \
-H "Authorization: Bearer bei_<hex>"
Tout ce qui n'est pas un simple Bearer bei_<hex> est refusé, pas
discrètement rétrogradé vers le palier anonyme.
Deux paliers
| Palier | Identifiant | Plafond compté par |
|---|---|---|
| anonyme | aucun | adresse IP |
| clé | bei_ | la clé |
Compter par clé plutôt que par IP est la raison pratique d'en détenir une : si vous appelez depuis une plateforme serverless, votre adresse change entre les invocations et un plafond compté par IP est inutilisable.
Pourquoi l'anonyme passe la vérification de scope
Un appelant anonyme satisfait toujours read:intelligence, et c'est
délibéré, pas une faille. Un scope contraint ce qu'un identifiant peut
faire. Il n'accorde rien. Ces endpoints sont publics par décision
produit, donc la permission d'un appelant anonyme vient du fait que la
route est ouverte, pas d'un token.
Un appelant qui a présenté une clé est lié par ce que dit cette clé.
Surfaces publiques
Plusieurs surfaces d'intelligence sont du HTML public et indexable :
/intelligence/inspect— inspecteurs mono-sonde (thème, apps, ads, e-mails)./intelligence/radar— le radar./intelligence/transparency— méthode et provenance.
Les enregistrements individuels sur /intelligence/stores/<domaine>
sont noindex, nofollow et exclus du sitemap. Ils restent
joignables pour les liens directs et les clients MCP, mais ce n'est pas
un corpus crawlable : une décision délibérée, puisqu'ils décrivent des
boutiques tierces.
Les liens sortants d'un enregistrement vers la boutique qu'il décrit
sont des URLs propres sans paramètres UTM et en rel="nofollow".
Comment nous nous identifions
Quand BoostEcom lit une boutique tierce, la requête porte le user-agent
BoostEcom-Scanner/1.0, qui cite
/about/scanner : la page de politique de bot qu'un
propriétaire de site trouvera dans ses logs. Cette page indique ce que
nous lisons et comment se retirer.
Ce qu'aucune clé ne débloque
Trois familles de champs ne sont ni derrière un paywall ni un scope : elles n'existent tout simplement pas, et aucune clé ne les produit :
- Le temps : depuis combien de temps une boutique fait quelque chose.
- Le volume : nombre absolu de commandes ou de revenu pour une boutique que nous ne possédons pas.
- La boutique elle-même : tout ce que seul son propriétaire peut voir.
Si un champ est absent d'une réponse, c'est la raison. Ce n'est pas une limitation de palier.