Intelligence API
Un accès programmatique en lecture seule à l'intelligence des boutiques, avec une clé bei_ : scope, limite de débit, et ce qu'atteint l'accès anonyme.
L'Intelligence API est en lecture seule. Tout ce qu'elle expose aujourd'hui est une lecture, et l'identifiant qui y donne accès le reflète.
La clé
Un jeton bei_, émis par BoostEcom et stocké sous forme de hash
SHA-256. Il porte le scope read:intelligence.
Ce scope est appliqué. Il faut le préciser, car ça n'a pas toujours été le cas : la colonne était enregistrée, lue au moment d'identifier l'appelant, et vérifiée nulle part. Le champ affichait donc le principe du moindre privilège sans jamais l'appliquer. Il a été activé alors que chaque clé émise ne portait encore que ce seul scope : le seul moment où l'appliquer ne bloquait personne.
curl https://boostecom.app/api/intelligence/top \
-H "Authorization: Bearer bei_<hex>"
Tout ce qui n'est pas exactement Bearer bei_<hex> est refusé, et
non rétrogradé en douce vers l'accès anonyme.
Deux paliers
| Palier | Identifiant | Limite comptée par |
|---|---|---|
| anonyme | aucun | adresse IP |
| clé | bei_ | la clé |
Le comptage par clé plutôt que par IP est la raison pratique d'en avoir une : si vous appelez depuis une plateforme serverless, votre adresse change d'une invocation à l'autre, et une limite comptée par IP devient inutilisable.
Pourquoi l'accès anonyme passe la vérification de scope
Un appelant anonyme satisfait toujours read:intelligence, et c'est
voulu, pas une faille. Un scope restreint ce qu'un identifiant peut
faire. Il n'accorde rien. Ces endpoints sont publics par décision
produit : la permission d'un appelant anonyme vient donc de l'ouverture
de la route, pas d'un jeton.
Un appelant qui a présenté une clé est tenu par ce que dit cette clé.
Surfaces publiques
Plusieurs surfaces d'intelligence sont des pages HTML publiques et indexables :
/intelligence/inspect: les inspecteurs à sonde unique (thème, apps, pubs, e-mails)./intelligence/radar: le radar./intelligence/transparency: méthode et provenance des données.
Les fiches individuelles sur /intelligence/stores/<domaine> sont en
noindex, nofollow et exclues du sitemap. Elles restent accessibles
par lien direct et pour les clients MCP, mais ne forment pas un corpus à
explorer : c'est un choix délibéré, puisqu'elles décrivent des boutiques
tierces.
Les liens sortants d'une fiche vers la boutique qu'elle décrit sont des
URL propres, sans paramètres UTM, en rel="nofollow".
Comment nous nous identifions
Quand BoostEcom lit une vitrine tierce, la requête porte le user-agent
BoostEcom-Scanner/1.0, qui renvoie vers
/about/scanner : la page de politique de robot qu'un
propriétaire de site trouvera dans ses journaux. Cette page indique ce
que nous lisons et comment s'y opposer.
Ce qu'aucune clé ne débloque
Trois familles de champs ne sont cachées ni derrière un paiement ni derrière 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 : le nombre absolu de commandes ou le chiffre d'affaires d'une boutique qui ne nous appartient pas.
- La boutique elle-même : tout ce que seul son propriétaire peut voir.
Si un champ manque dans une réponse, voilà pourquoi. Il ne s'agit pas d'une limite liée au palier.