Authentification : les clés d'API

Obtenir une clé

Les clés se créent et se gèrent sur Mon compte → Mon API. Il faut un compte LogiScan ordinaire — adresse et mot de passe, rien d'autre — et, pour appeler en réel, des crédits.

Une clé a la forme lsk_live_ ou lsk_test_, suivie de huit caractères d'identifiant puis de trente-deux caractères secrets. Seuls les seize premiers (le préfixe) sont conservés en clair : c'est ce que vos pages et le poste de pilotage affichent. Le secret est haché (HMAC-SHA256, salé par un secret du service) et ne peut pas être relu — pas même par nous.

Le secret s'affiche une seule fois, à la création. Si vous le perdez, faites tourner la clé : vous en obtenez une nouvelle, l'ancienne répond encore le temps du sursis.

Deux modes : bac à sable et réel

Une clé lsk_test_ appelle les mêmes routes, avec les mêmes formes de réponse, et ne coûte rien : les réponses sont fictives, tirées d'un jeu figé (une commune qui n'existe pas, des ventes inventées à partir d'une vraie forme de réponse). Aucune source réelle n'est lue, votre solde n'est pas touché. C'est la façon d'écrire votre client sans payer.

Une clé lsk_live_ rend de vraies données et consomme des crédits. Un compte a au plus une clé active par mode ; en créer une seconde demande de révoquer ou de faire tourner la première.

Présenter la clé

Chaque appel porte l'en-tête Authorization: Bearer <clé>. Rien d'autre n'est lu : ni paramètre d'adresse, ni cookie. Une clé absente, mal formée, inconnue ou révoquée reçoit la même réponse — 401 invalid_key — pour qu'on ne puisse pas distinguer une clé qui n'existe pas d'une clé qui a existé.

curl -s 'https://logiscan.fr/v1/account' \
  -H 'Authorization: Bearer lsk_test_VOTRE_CLE'

import httpx

CLE = "lsk_test_VOTRE_CLE"

reponse = httpx.get(
    "https://logiscan.fr/v1/account",
    headers={"Authorization": f"Bearer {CLE}"},
    timeout=30,
)
print(reponse.status_code, reponse.json())

const CLE = "lsk_test_VOTRE_CLE";

const reponse = await fetch("https://logiscan.fr/v1/account", {
  method: "GET",
  headers: { Authorization: `Bearer ${CLE}` },
});
console.log(reponse.status, await reponse.json());

{
  "email": "vous@exemple.fr",
  "key": {
    "prefixe": "lsk_test_BACASABL",
    "libelle": "bac à sable",
    "mode": "test",
    "created_at": "2026-09-01T09:00:00Z",
    "expires_at": null
  },
  "balance_credits": 0.0,
  "usage": {
    "24h": {
      "calls": 3,
      "credits": 0.0
    },
    "7d": {
      "calls": 3,
      "credits": 0.0
    },
    "30d": {
      "calls": 3,
      "credits": 0.0
    },
    "90d": {
      "calls": 3,
      "credits": 0.0
    }
  },
  "tarifs": {
    "account": 0.0,
    "analyses.listing_url": 1.0,
    "analyses.listing_text": 0.6,
    "analyses.address": 0.6,
    "dpe": 0.1,
    "listings.completeness": 0.05
  }
}

Faire tourner une clé sans interruption

Sur Mon API, « Faire tourner » crée une nouvelle clé et laisse l'ancienne répondre pendant un sursis (une heure par défaut). Pendant ce temps, les deux répondent ; GET /v1/account avec l'ancienne porte alors key.expires_at, la date à laquelle elle cessera. Déployez la nouvelle, puis laissez l'ancienne s'éteindre — ou révoquez-la sur-le-champ.

Révoquer

« Révoquer » coupe une clé immédiatement, qu'elle soit active ou en sursis. Elle répond ensuite 401. Les crédits restent sur le compte : ils appartiennent au compte, pas à la clé.

Nous révoquons nous-mêmes une clé employée pour une collecte de masse : chaque appel est une lecture unitaire, et c'est écrit dans les conditions.

Bonnes pratiques

• Gardez la clé côté serveur, dans une variable d'environnement ou un coffre — jamais dans un navigateur, une application mobile ou un dépôt.
• Une clé par environnement : le bac à sable en développement et en intégration continue, le réel en production.
• Faites tourner la clé après un départ d'équipe ou une fuite supposée ; le sursis rend le geste sans risque.