La Intelligence API es de solo lectura. Todo lo que expone hoy es una lectura, y la credencial lo refleja.
La clave
Un token bei_, emitido por BoostEcom y almacenado como hash SHA-256.
Lleva el scope read:intelligence.
Ese scope se aplica. Vale la pena decirlo porque no siempre fue así: la columna se almacenaba, se parseaba en el llamante, y no se verificaba en ningún sitio, así que el campo anunciaba el mínimo privilegio y no aplicaba ninguno. Se activó mientras cada clave emitida todavía llevaba exactamente ese único scope, el único momento en que aplicarlo no dejó a nadie fuera.
curl https://boostecom.app/api/intelligence/top \
-H "Authorization: Bearer bei_<hex>"
Cualquier cosa que no sea un simple Bearer bei_<hex> se rechaza,
no se degrada silenciosamente al nivel anónimo.
Dos niveles
| Nivel | Credencial | Techo contado por |
|---|---|---|
| anónimo | ninguna | dirección IP |
| clave | bei_ | la clave |
Contar por clave en lugar de por IP es la razón práctica para tener una: si llamas desde una plataforma serverless, tu dirección cambia entre invocaciones y un techo contado por IP es inutilizable.
Por qué el anónimo pasa la verificación de scope
Un llamante anónimo siempre satisface read:intelligence, y eso es
deliberado, no un agujero. Un scope restringe lo que una credencial
puede hacer. No otorga nada. Estos endpoints son públicos por
decisión de producto, así que el permiso de un llamante anónimo viene
de que la ruta esté abierta, no de un token.
Un llamante que sí presentó una clave está limitado por lo que dice esa clave.
Superficies públicas
Varias superficies de inteligencia son HTML público e indexable:
/intelligence/inspect: inspectores de sonda única (tema, apps, ads, correos)./intelligence/radar: el radar./intelligence/transparency: método y procedencia.
Los registros individuales en /intelligence/stores/<dominio> son
noindex, nofollow y están excluidos del sitemap. Siguen siendo
alcanzables para enlaces directos y para clientes MCP, pero no son un
corpus rastreable: una decisión deliberada, ya que describen tiendas
de terceros.
Los enlaces salientes de un registro hacia la tienda que describe son
URLs limpias sin parámetros UTM y con rel="nofollow".
Cómo nos identificamos
Cuando BoostEcom lee un storefront de un tercero, la solicitud lleva
el user-agent BoostEcom-Scanner/1.0, que cita
/about/scanner: la página de política de bots que
un propietario de sitio encontrará en sus logs. Esa página indica qué
leemos y cómo optar por no participar.
Lo que ninguna clave desbloquea
Tres familias de campos no están tras un muro de pago ni un scope: simplemente no existen, y ninguna clave las produce:
- Tiempo: cuánto tiempo lleva una tienda haciendo algo.
- Volumen: recuentos absolutos de pedidos o ingresos de una tienda que no poseemos.
- La propia tienda: cualquier cosa que solo su propietario pueda ver.
Si un campo está ausente de una respuesta, esa es la razón. No es una limitación de nivel.