A Intelligence API é somente leitura. Tudo que ela expõe hoje é uma leitura, e a credencial reflete isso.
A chave
Um token bei_, emitido pelo BoostEcom e armazenado como hash
SHA-256. Ele carrega o escopo read:intelligence.
Esse escopo é aplicado. Vale a pena dizer porque nem sempre foi assim: a coluna era armazenada, interpretada no chamador, e verificada em lugar nenhum, então o campo anunciava o mínimo privilégio e não aplicava nenhum. Foi ativado enquanto toda chave emitida ainda carregava exatamente aquele único escopo, o único momento em que aplicá-lo não excluiu ninguém.
curl https://boostecom.app/api/intelligence/top \
-H "Authorization: Bearer bei_<hex>"
Qualquer coisa diferente de um simples Bearer bei_<hex> é
recusada, não silenciosamente rebaixada ao nível anônimo.
Dois níveis
| Nível | Credencial | Teto contado por |
|---|---|---|
| anônimo | nenhuma | endereço IP |
| chave | bei_ | a chave |
Contar por chave em vez de por IP é o motivo prático para possuir uma: se você chama de uma plataforma serverless, seu endereço muda entre invocações e um teto contado por IP é inutilizável.
Por que o anônimo passa na verificação de escopo
Um chamador anônimo sempre satisfaz read:intelligence, e isso é
deliberado, não uma falha. Um escopo restringe o que uma credencial
pode fazer. Ele não concede nada. Esses endpoints são públicos por
decisão de produto, então a permissão de um chamador anônimo vem do
fato de a rota estar aberta, não de um token.
Um chamador que apresentou uma chave é limitado pelo que essa chave diz.
Superfícies públicas
Várias superfícies de intelligence são HTML público e indexável:
/intelligence/inspect: inspetores de sonda única (tema, apps, ads, e-mails)./intelligence/radar: o radar./intelligence/transparency: método e proveniência.
Registros individuais em /intelligence/stores/<dominio> são
noindex, nofollow e excluídos do sitemap. Continuam
alcançáveis por links diretos e por clientes MCP, mas não são um
corpus rastreável, uma decisão deliberada, já que descrevem lojas de
terceiros.
Links de saída de um registro para a loja que ele descreve são URLs
limpas sem parâmetros UTM e com rel="nofollow".
Como nos identificamos
Quando o BoostEcom lê uma vitrine de terceiros, a requisição carrega o
user agent BoostEcom-Scanner/1.0, que cita
/about/scanner: a página de política de bots que
um dono de site encontrará em seus logs. Aquela página declara o que
lemos e como fazer opt-out.
O que nenhuma chave desbloqueia
Três famílias de campo não estão atrás de um paywall ou de um escopo: elas simplesmente não existem, e nenhuma chave as produz:
- Tempo: há quanto tempo uma loja está fazendo algo.
- Volume: contagens absolutas de pedidos ou receita de uma loja que não possuímos.
- A loja em si: qualquer coisa que só o dono dela pode ver.
Se um campo está ausente de uma resposta, essa é a razão. Não é uma limitação de nível.