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 countGET /api/v1/brandsyour monitored brands, with market, sector, competitors and measurement datesGET /api/v1/brands/:id/snapshots?limit=24one brand's dated history, newest first, with the public report URL per pointGET /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.