Développeurs
API et MCP
Une clé, deux portes : l'API REST v1 pour vos outils, le serveur MCP pour vos assistants IA. Les deux lisent les mêmes mesures que votre portail - re-mesurées tous les 3 jours - et ne déclenchent rien : la lecture seule est un choix, pas un manque.
Votre clé
La clé se génère depuis votre portail de gestion (section « API et MCP »). Elle s'affiche une seule fois, une seule clé active par compte - en générer une nouvelle révoque l'ancienne. Envoyez-la en en-tête :
curl https://waseit.net/api/v1/brands \
-H "Authorization: Bearer wa_live_VOTRE_CLE"L'API v1, en lecture seule
GET /api/v1/mele compte derrière la clé : plan, langue, nombre de marquesGET /api/v1/brandsvos marques suivies, avec marché, secteur, concurrents et dates de mesureGET /api/v1/brands/:id/snapshots?limit=24l'historique daté d'une marque, du plus récent au plus ancien, avec l'URL du rapport public par pointGET /api/v1/brands/:id/latestla dernière mesure et son delta face à la précédente (null tant qu'il n'y a qu'un point)
Description machine complète : openapi.json
Le serveur MCP
Le même compte, parlé par un assistant : ChatGPT, Claude ou tout client MCP peut lister vos marques, lire la dernière mesure et l'historique. Transport « Streamable HTTP », authentification par la même clé. Ajoutez ce connecteur :
{
"mcpServers": {
"waseit": {
"url": "https://waseit.net/api/mcp",
"headers": { "Authorization": "Bearer wa_live_VOTRE_CLE" }
}
}
}Outils exposés : list_brands, get_latest_measurement(brand), get_score_history(brand, limit). Les marques s'adressent par leur nom.
Ce que l'API ne fera pas
- Déclencher une mesure : les mesures arrivent par la cadence de 3 jours, l'API les lit. Une API d'écriture serait une surface d'abus avant d'être un service.
- Vous donner un chiffre que le portail n'a pas : l'API expose les snapshots que le produit fabrique, jamais un calcul parallèle qui pourrait diverger.
- Promettre un classement : chaque réponse est une mesure datée - c'est toute la thèse.