# L'API Storelift

URL: https://storelift.net/fr/guide/storelift-api/
Language: fr
Updated: 2026-09-20

Tout ce que montre le tableau de bord existe aussi sous forme d'endpoint JSON. Il y en a 9, tous en GET, tous sur vos propres apps suivies : un script, une tâche de tableur ou une étape de CI peut lire les mêmes chiffres sans scraper de page. L'API est incluse dans Pro et Studio ; un assistant qui lit les mêmes données préférera en général le serveur MCP.

## Adresse de base et authentification

La base est https://storelift.net/v1. Créez une clé dans Settings → API ; elle n'est affichée qu'une fois et stockée uniquement sous forme de hash : une clé perdue se remplace, elle ne se récupère pas.

Envoyez-la dans x-api-key, ou comme jeton bearer si votre client ne gère que les en-têtes Authorization :

curl -s https://storelift.net/v1/apps \
-H "x-api-key: sl_live_..."

NOTE: L'accès à l'API est inclus dans les plans Pro et Studio : à partir de 20 $ par mois, 60 $ pour Studio. Si le plan est rétrogradé, la clé cesse de fonctionner mais n'est pas supprimée : repasser au plan supérieur réactive la même intégration.

## Les 9 endpoints

| Endpoint | Ce qu'il renvoie |
| --- | --- |
| GET /v1/apps | Les apps suivies par ce compte. Tous les autres appels partent de là : l'id vient de celui-ci. |
| GET /v1/apps/{id} | Une app et l'instantané de la dernière exécution. |
| GET /v1/apps/{id}/keywords | Le classement actuel de chaque mot-clé suivi dans un storefront, avec l'état de la mesure et la profondeur de recherche. |
| GET /v1/apps/{id}/rivals | Les apps placées au-dessus de vous, chacune avec les termes sur lesquels elle vous devance et les deux positions. |
| GET /v1/apps/{id}/ai | Si un assistant cite votre app pour votre catégorie, avec la série enregistrée. Studio le mesure. |
| GET /v1/apps/{id}/history | La série de classement par mot-clé, tronquée à la fenêtre d'historique du plan. |
| GET /v1/apps/{id}/page | Votre propre fiche telle que le store la sert, sur les deux plateformes, avec les changements datés qui y ont été détectés. |
| GET /v1/apps/{id}/reviews | Les avis récents avec le résumé des étoiles, le nombre de nouveaux avis dans cette exécution, et le côté Play quand il est mesuré. |
| GET /v1/apps/{id}/charts | La position dans le top pour la catégorie et le storefront de l'app, avec la série. |

Les endpoints sous /apps/{id} acceptent country (un code de storefront comme us, par défaut le premier de l'app) et, quand les deux stores sont mesurés, platform=ios|android.

## Les trois états de mesure passent la frontière intacts

C'est la partie à lire avant d'écrire l'intégration. Un champ de classement peut contenir un nombre, mais l'absence de nombre recouvre deux choses différentes, et l'API les garde séparées :

- measured: true, rank: 7 : l'app a été trouvée en position 7.
- measured: true, rank: null : la recherche a tourné et l'app n'était pas dans les résultats à la profondeur que nous lisons.
- measured: false : la recherche n'a pas pu être lancée ce jour-là. On ne sait rien de la position.

{
"country": "de",
"platform": "ios",
"live": true,
"measuredAt": "2026-09-19T02:14:08.921Z",
"keywords": [
{ "term": "traumdeutung", "measured": true, "rank": 7, "demand": 6, "searchDepth": 200 },
{ "term": "traumsymbole", "measured": true, "rank": null, "demand": 3, "searchDepth": 200 },
{ "term": "traumtagebuch", "measured": false, "rank": null, "demand": null, "searchDepth": null }
]
}

Fondre les deux derniers en zéro décrirait un effondrement qui n'a jamais eu lieu, et toute moyenne construite dessus serait fausse. Si votre code a besoin d'un seul nombre, traitez measured: false comme un trou dans la série, pas comme une valeur.

## Ce qu'elle ne fait pas

- Elle n'écrit rien. Chaque endpoint est en GET ; toute autre méthode renvoie method_not_allowed. Aucun chemin ne mène de l'API à votre fiche, à vos mots-clés suivis ou à votre facturation.
- Elle ne mesure pas à la demande. Les endpoints lisent ce que l'exécution nocturne a collecté. Demander deux fois n'envoie pas une deuxième requête aux stores.
- Elle ne porte pas la couche revenus. Les comptes connectés (App Store Connect, Apple Ads, RevenueCat, GA4) restent dans le tableau de bord : c'est une limite délibérée, pas un oubli.
- L'historique est tronqué selon le plan. history et charts coupent tous deux à la fenêtre du plan : la même clé ne peut pas remonter plus loin par un endpoint que par l'autre.

## Erreurs

| Statut | error | Quand |
| --- | --- | --- |
| 401 | missing_api_key | Aucune clé dans la requête. |
| 401 | invalid_api_key | La clé est inconnue ou a été révoquée. |
| 401 | account_deleted | Le compte associé à la clé n'existe plus. |
| 403 | plan_required | Le plan n'inclut pas l'accès à l'API. La réponse indique le plan actuel. |
| 405 | method_not_allowed | Chaque endpoint est en GET. Rien n'écrit. |
| 404 | not_found | Cet id d'app n'appartient pas à ce compte. |
| 404 | unknown_endpoint | Ce chemin n'existe pas sous /v1. |

Chaque erreur est un JSON avec un champ error. plan_required renvoie aussi plan, pour qu'un client puisse dire sur quel plan est la clé au lieu de deviner.

## FAQ

Q: Y a-t-il une limite de débit ?
A: Il n'y a pas de quota par clé. La passerelle devant l'API a un plafond à l'échelle du compte, et chaque appel met à jour un compteur d'utilisation sur la clé : vous voyez dans les réglages si une ancienne clé sert encore.

Q: Puis-je l'utiliser avec le plan gratuit ?
A: Non : l'accès à l'API commence avec Pro. Les outils gratuits de ce site ne demandent aucun compte, et le plan gratuit mesure quand même une app chaque jour.

Q: API ou serveur MCP ?
A: Un script veut l'API : formats fixes, un appel, aucun modèle dans la boucle. Un assistant veut le serveur MCP, parce que les outils portent leurs propres descriptions et qu'il peut choisir le bon appel sans que vous écriviez l'intégration. Les deux lisent les mêmes mesures.