Die Intelligence API ist schreibgeschützt. Alles, was sie heute offenlegt, ist ein Lesevorgang, und die Anmeldeinformation spiegelt das wider.
Der Schlüssel
Ein bei_-Token, von BoostEcom ausgestellt und als SHA-256-Hash
gespeichert. Er trägt den Scope read:intelligence.
Dieser Scope wird durchgesetzt. Es lohnt sich, das zu sagen, weil es nicht immer so war: die Spalte wurde gespeichert, in den Aufrufer geparst, und nirgends geprüft, sodass das Feld geringste Privilegien ankündigte und keine durchsetzte. Es wurde aktiviert, während jeder ausgegebene Schlüssel noch genau diesen einen Scope trug, der einzige Moment, in dem das Durchsetzen niemanden ausgesperrt hätte.
curl https://boostecom.app/api/intelligence/top \
-H "Authorization: Bearer bei_<hex>"
Alles außer einem reinen Bearer bei_<hex> wird abgelehnt, nicht
still auf die anonyme Stufe herabgestuft.
Zwei Stufen
| Stufe | Anmeldeinformation | Obergrenze gezählt nach |
|---|---|---|
| anonym | keine | IP-Adresse |
| Schlüssel | bei_ | dem Schlüssel |
Pro Schlüssel statt pro IP zu zählen ist der praktische Grund, einen zu besitzen: wenn Sie von einer serverlosen Plattform aus aufrufen, ändert sich Ihre Adresse zwischen Aufrufen, und eine nach IP gezählte Obergrenze ist unbrauchbar.
Warum Anonym die Scope-Prüfung besteht
Ein anonymer Aufrufer erfüllt immer read:intelligence, und das ist
beabsichtigt, keine Lücke. Ein Scope schränkt ein, was eine
Anmeldeinformation tun darf. Er gewährt nichts. Diese Endpunkte sind
per Produktentscheidung öffentlich, sodass die Berechtigung eines
anonymen Aufrufers daher kommt, dass die Route offen ist, nicht von
einem Token.
Ein Aufrufer, der tatsächlich einen Schlüssel vorgelegt hat, ist an das gebunden, was dieser Schlüssel sagt.
Öffentliche Oberflächen
Mehrere Intelligence-Oberflächen sind öffentliches, indexierbares HTML:
/intelligence/inspect— Einzelsonden- Inspektoren (Theme, Apps, Ads, E-Mails)./intelligence/radar: das Radar./intelligence/transparency— Methode und Herkunft.
Einzelne Datensätze unter /intelligence/stores/<domain> sind
noindex, nofollow und aus dem Sitemap ausgeschlossen. Sie
bleiben für Direktlinks und für MCP-Clients erreichbar, sind aber kein
crawlbarer Korpus — eine bewusste Entscheidung, da sie Stores Dritter
beschreiben.
Ausgehende Links von einem Datensatz zum beschriebenen Store sind
saubere URLs ohne UTM-Parameter und mit rel="nofollow".
Wie wir uns identifizieren
Wenn BoostEcom einen Storefront eines Dritten liest, trägt die Anfrage
den User-Agent BoostEcom-Scanner/1.0, der
/about/scanner zitiert — die Bot-Richtlinienseite,
die ein Website-Betreiber in seinen Logs findet. Diese Seite gibt an,
was wir lesen und wie man sich abmeldet.
Was kein Schlüssel freischaltet
Drei Feldfamilien stehen weder hinter einer Paywall noch einem Scope: sie existieren schlicht nicht, und kein Schlüssel erzeugt sie:
- Zeit — wie lange ein Store bereits etwas tut.
- Volumen — absolute Bestell- oder Umsatzzahlen für einen Store, den wir nicht besitzen.
- Der Store selbst: alles, was nur sein Eigentümer sehen kann.
Fehlt ein Feld in einer Antwort, ist das der Grund. Es ist keine Stufenbeschränkung.