SDKs serveur

Les SDKs serveur envoient des événements depuis votre backend avec la write key secrète de votre projet. Les événements envoyés ainsi sont des faits : la plateforme les marque source=server et verified=true, car détenir la clé secrète est l’authentification. C’est ce qui en fait le bon canal pour tout ce dont dépendent l’argent ou la messagerie — commandes, remboursements, changements d’abonnement — plutôt qu’un track('purchase') dans le navigateur que n’importe qui peut falsifier depuis la console.

Ils sont volontairement petits. Pas d’autocapture, pas de session replay, pas d’identité persistée : vous passez le distinct_id à chaque appel. Cinq langages, une spécification partagée — même comportement, même format de wire, mêmes test vectors : ce que vous apprenez dans l’un vaut dans les autres.

Langage	Paquet	Statut	Dépôt
PHP	composer require kilden/kilden-php:@alpha	Alpha	kilden-sdk-php
Node.js	npm install @kilden-io/node@alpha	Alpha	kilden-sdk-node
Python	pip install kilden	Stable	kilden-sdk-python
Ruby	gem install kilden	Stable	kilden-sdk-ruby
Go	go get go.kilden.io/sdk@latest	Alpha	kilden-sdk-go

Python et Ruby ont publié une version stable ; PHP, Node.js et Go non : leurs dernières versions publiées sont encore en alpha.

Cela se traduit par deux mécanismes distincts. PHP et Node.js exigent que le canal alpha soit nommé explicitement : sans :@alpha, Composer ne résout rien et échoue, et un npm install @kilden-io/node nu prend le dist-tag latest, en retard sur l’alpha actuelle. Le @latest de Go, lui, n’est pas un sélecteur de préversion : il préfère la dernière version stable et ne retombe sur une préversion que parce qu’aucune n’existe encore, si bien que cette commande continuera de fonctionner telle quelle le jour où une version stable paraîtra.

Le cœur PHP alimente aussi kilden/laravel, qui ajoute à une app Laravel une facade, l’envoi par queue, une route POST /kilden/identity prête à l’emploi et la directive Blade @kildenScript — le loader du SDK web, déjà branché sur l’identité.

La règle clé

Les SDKs serveur prennent la clé secrète (sk_…), jamais la publique. Le constructeur rejette d’emblée une clé publique. L’inverse vaut aussi : la clé secrète ne doit jamais atteindre un navigateur ni un bundle d’app — traitez-la comme le mot de passe de votre base de données. Les SDKs client (web, Expo / React Native) en sont l’image miroir : ils prennent la clé publique et rejettent les secrètes. Le modèle complet est décrit dans niveaux de confiance.

Ce qu’ils font

• Événements — track, identify, alias, mis en lot en mémoire et livrés en arrière-plan avec retries, gzip et UUIDs idempotents. Vous appelez close() à l’arrêt ; le reste est automatique (sous PHP-FPM le shutdown hook flushe après l’envoi de la réponse).
• Signature d’identité — IdentitySigner produit le JWT de courte durée qu’exige la vérification d’identité, en trois lignes, sans dépendance JWT. C’est la raison d’être de ces SDKs.
• Feature flags — isEnabled / getFeatureFlag évalués par Kilden (/decide) avec un cache in-process de 30 secondes, un timeout strict et un default que vous contrôlez, pour que votre chemin de requête ne dépende jamais de nous.

Commencez par le quickstart : premier événement, identify et un jeton d’identité signé dans chaque langage.