跳到正文
Waseit

Developers

API and MCP

One key, two doors: the v1 REST API for your tools, the MCP server for your AI assistants. Both read the same measurements as your portal - re-run every 3 days - and trigger nothing: read-only is a choice, not a gap.

Your key

Generate the key from your manage portal (« API and MCP » section). It is shown once, one active key per account - minting a new one revokes the old. Send it as a header:

curl https://waseit.net/api/v1/brands \
  -H "Authorization: Bearer wa_live_VOTRE_CLE"

The v1 API, read-only

  • GET /api/v1/methe account behind the key: plan, locale, brand count
  • GET /api/v1/brandsyour monitored brands, with market, sector, competitors and measurement dates
  • GET /api/v1/brands/:id/snapshots?limit=24one brand's dated history, newest first, with the public report URL per point
  • GET /api/v1/brands/:id/latestthe latest measurement and its delta vs the previous one (null while there is a single point)

Full machine-readable description: openapi.json

The MCP server

The same account, spoken by an assistant: ChatGPT, Claude or any MCP client can list your brands, read the latest measurement and the history. « Streamable HTTP » transport, authenticated with the same key. Add this connector:

{
  "mcpServers": {
    "waseit": {
      "url": "https://waseit.net/api/mcp",
      "headers": { "Authorization": "Bearer wa_live_VOTRE_CLE" }
    }
  }
}

Exposed tools: list_brands, get_latest_measurement(brand), get_score_history(brand, limit). Brands are addressed by name.

What the API will not do

  • Trigger a measurement: measurements arrive on the 3-day cadence, the API reads them. A write API would be an abuse surface before being a service.
  • Give you a number the portal does not have: the API exposes the snapshots the product makes, never a parallel computation that could diverge.
  • Promise a ranking: every response is a dated measurement - that is the whole thesis.

The key is included in every plan