Authentification

Chaque requête porte une clé API dans l’en-tête Authorization :

Authorization: Bearer lp_live_XXXXXXXX…    (clé d’espace de travail)
Authorization: Bearer lpp_live_XXXXXXXX…   (clé partenaire)

Les clés sont créées dans le tableau de bord, affichées une seule fois à la création et stockées sous forme d’empreinte SHA-256 — personne, support compris, ne peut récupérer une clé perdue. Perdre une clé signifie la révoquer et en créer une nouvelle.

Types de clés

• Clés d’espace de travail (lp_live_…) agissent dans un seul espace de travail : liens, statistiques, domaines, journal d’audit et webhooks de l’espace. Créées par les administrateurs de l’espace dans Réglages → Clés API.
• Clés partenaires (lpp_live_…) agissent sur le compte partenaire : clients, forfaits, domaines, paiements, versements et webhooks partenaires. Créées par les administrateurs partenaires.

Une clé d’espace de travail qui appelle /partner/* (ou l’inverse) reçoit 403 forbidden — les familles d’endpoints sont strictement séparées.

Portées

Les portées sont accordées par clé, à la création. Une requête a besoin de toutes les portées exigées par son endpoint ; une portée manquante répond 403 insufficient_scope en nommant la portée absente.

| Portée | Autorise | |---|---| | links:read / links:write | Lire / créer, modifier, archiver, supprimer des liens | | analytics:read | Synthèse, séries temporelles, répartitions, meilleurs liens, export CSV — et la vue d’ensemble des clics à l’échelle du partenaire | | domains:read / domains:write | Lire / connecter et déconnecter des domaines | | qr:read | Générer les QR codes des liens | | workspace:read | Profil de l’espace de travail, limites, journal d’audit | | webhooks:read / webhooks:write | Lire / gérer les endpoints de webhooks | | partner:read | Profil, forfait et consommation du partenaire | | clients:read / clients:write | Lire / créer, modifier, suspendre des clients | | plans:read / plans:write | Lire / gérer les forfaits partenaires | | payments:read | Miroir des paiements et versements |

C’est la liste complète — quinze portées, et une clé ne peut porter que des noms qui y figurent. Les QR codes sont en lecture seule via l’API : en générer un demande qr:read, et il n’existe pas de portée d’écriture QR parce qu’il n’existe pas d’endpoint de mutation QR.

Une association surprend souvent : GET /partner/analytics/overview demande analytics:read sur la clé partenaire, et non partner:read. Tous les endpoints analytiques utilisent la même portée, quel que soit le type de clé.

Donnez à chaque intégration sa propre clé avec le minimum de portées dont elle a besoin : une clé de widget de tableau de bord se contente très bien de links:read + analytics:read, tandis qu’un script de provisionnement a besoin de clients:write.

Restriction par forfait

L’accès à l’API est une fonctionnalité de forfait (api_access) :

• pour les clés d’espace de travail, le forfait de l’espace et le forfait plateforme du partenaire doivent tous deux inclure l’accès à l’API ;
• pour les clés partenaires, le forfait plateforme du partenaire doit l’inclure.

Un forfait sans accès à l’API répond 403 plan_restricted. Les espaces de travail en essai, sans forfait, ne sont pas restreints.

Rotation et révocation

Révoquer une clé prend effet immédiatement : la requête suivante répond 401 unauthorized. Pour effectuer une rotation sans interruption, créez d’abord la nouvelle clé, basculez l’intégration, puis révoquez l’ancienne. Chaque clé enregistre last_used_at : une ancienne clé inutilisée est facile à repérer avant de la révoquer.

Une clé peut aussi porter une date d’expiration — les clés expirées se comportent exactement comme les clés révoquées.

Bonnes pratiques

• Les clés sont des secrets : gardez-les dans un gestionnaire de secrets, jamais dans du code côté client, des dépôts ou des journaux.
• Une clé par intégration — en révoquer une ne casse pas les autres, et le journal d’audit attribue chaque changement à la clé qui l’a effectué.