Développez avec Praxium.

Les clés API sont signées en HMAC à la création : la clé porte sa propre preuve d’intégrité, au format praxium_v1_<tenant>_<profile>_<timestamp>_<signature>, où la signature est dérivée côté serveur en HMAC-SHA256 à partir d’un secret de signature propre à chaque profil, conservé chiffré en base — le secret ne circule jamais sur le réseau, seule circule la signature qu’il produit. Le nom court de l’organisation est lié cryptographiquement à la signature : une clé émise pour l’organisation A ne peut donc pas être réutilisée sur l’organisation B sans casser la vérification. À l’arrivée, le serveur vérifie l’intégrité de la clé avant de renvoyer la moindre donnée, et les clés falsifiées ou détournées reçoivent un 403.

Les requêtes s’authentifient avec le classique Authorization: Bearer <key> en HTTPS — le même schéma que GitHub, OpenAI, Slack et Notion.

Par-dessus, chaque clé appartient à un seul profil API, qui définit précisément les types de données et les champs qu’elle peut lire. Chaque intégration ne touche que les données dont elle a besoin — le principe du moindre privilège, appliqué au champ près plutôt qu’au point de terminaison. La révocation et la rotation se font par profil depuis le portail d’administration.

Envoyez Accept-Language: nl, Accept-Language: en ou Accept-Language: ro quand votre site n’affiche qu’une langue. Les API utilisent la langue demandée uniquement si l’organisation l’a activée ; sinon elles utilisent sa langue par défaut.

Chaque point de terminaison conserve une seule forme de réponse documentée. Les champs documentés comme traduits — noms de catégories de FAQ, questions et réponses, libellés et valeurs des champs personnalisés de l’équipe — reviennent sous forme de chaînes. Les champs documentés en OpenAPI comme cartes de langues conservent cette forme.

Pour les champs traduits, une traduction absente retombe sur le meilleur texte publié disponible plutôt que sur une chaîne vide.

Chaque livraison porte un seul en-tête X-Praxium-Signature: t=<unix_ts>,sha256=<hmac_hex>, où le HMAC-SHA256 est calculé côté serveur sur ${timestamp}.${rawBody} avec le secret propre au webhook. Le secret partagé ne circule jamais sur le réseau — seul circule le résultat du HMAC. La signature prouve deux choses à la fois : que le corps n’a pas été altéré en chemin (intégrité) et que l’appel vient bien de Praxium et non de quelqu’un qui a deviné l’adresse de votre point de terminaison (authenticité). Toutes les livraisons passent en HTTPS — Praxium refuse d’enregistrer une adresse de webhook non HTTPS dans les environnements publiés.

En tant que destinataire, c’est à vous de vérifier chaque livraison — Praxium signe et envoie, mais le contrôle a lieu dans votre gestionnaire. Avec @praxium/sdk, vous n’écrivez rien de tout cela à la main : processWebhook() (indépendant du framework) et createRevalidationHandler() (ISR de Next.js) enchaînent les quatre étapes et la protection contre les renvois. Vous l’implémentez dans un autre environnement ? Les quatre étapes sont : (1) lisez l’instant et la signature dans l’en-tête, (2) rejetez les livraisons plus anciennes que votre fenêtre de renvoi — 5 minutes est la norme, (3) recalculez le HMAC sur ${timestamp}.${rawBody} avec votre secret partagé, (4) comparez en temps constant (par exemple crypto.timingSafeEqual sur Node).

C’est le schéma que Stripe utilise pour signer ses webhooks. Le secret d’un webhook n’est renvoyé qu’une seule fois — dans la réponse qui crée le webhook et dans chaque réponse de rotation — puis il ne réapparaît plus. Cette exposition unique fait qu’aucune surface d’attaque durable ne subsiste côté plateforme : même une session d’administration compromise ne pourrait pas le relire. Il vous en faut un nouveau ? Faites-le tourner depuis le portail d’administration — le nouveau secret arrive dans la réponse, le précédent perd aussitôt sa validité et les autres abonnements ne bougent pas.