API de licences logicielles : activation, validation et signaux de présence

Choisissez la langue et l’opération, puis appelez le SDK. Il gère l’activation, l’identité de l’appareil, les signatures, le cache, les battements et les réservations, confirmations et annulations d’usage.

Démarrage ou écran d’activationAvant une fonction payanteÀ la fermeture de l’application

Common scenario snippets

Dans ces exemples, client vient du démarrage, path est le chemin d’exportation et exportReport / export_report est votre fonction métier. Le jobID compté est un identifiant stable conservé par l’application.

Voir le code complet → · Démarrage rapide · Voir l’intégration comptée et les reprises →

Placez le code métier dans le rappel.

Le SDK exécute seulement les opérations autorisées. RunFeature ne déduit aucun usage ; RunMeteredFeature réserve, confirme le succès et annule l’échec. Reprendre la tâche initiale confirme sans répéter l’opération terminée.

Complete SDK method reference

The scenarios above are short call snippets. Below are the current language’s public methods, properties and utilities, including full signatures, parameters, results, errors, configuration and data fields. The reference follows the selected language and identifies capabilities that are unavailable in a wrapper.

Afficher les requêtes et réponses HTTP (clients personnalisés ou dépannage)

Le protocole ci-dessous est implémenté par les SDK. Les applications utilisant ces neuf SDK n’ont pas à le réimplémenter.

Première activationHeartbeat à l’exécutionVérifier les droits avant l’opérationLibérer avant un changement d’appareil

Ces huit interfaces authentifient licence et appareil, sans cookies, CSRF ni clé de gestion. Les sessions flottantes sont libérées à l’arrêt ; les appareils liés restent enregistrés.

Comment vérifier l’accès après activation, vérification ou heartbeat ?

Vérifiez HTTP 200 et lisez data.activation_id. Joignez cet ID aux vérifications, heartbeats, comptages et libérations suivants.
Vérifiez avec la clé publique du produit préapprouvée data.lease puis vérifiez produit, appareil, validité et fonctionnalités. Décoder payload en JSON ne prouve pas la validité de l’autorisation.
Le SDK automatise les deux premières étapes. RunFeature vérifie l’accès avant le travail ; RunMeteredFeature gère réservation, confirmation et annulation pour les compteurs.

Le SDK conserve le cache signé et envoie les heartbeats selon la stratégie. N’effacez pas un cache valide pour un simple délai réseau. En cas de révocation, libération ou expiration explicite, bloquez les fonctions protégées selon le résultat du SDK.

Que signifient les champs du payload décodé ?

L’exemple explique les données. Pour vérifier la signature vous-même, utilisez les octets originaux de payload reçu ; ne réordonnez ni ne sérialisez le JSON.

Tentatives, heartbeats et facturation

Requis pour activation, libération et comptage Idempotency-Key, jusqu’à 80 caractères sans espace. Nouvelle opération : nouvelle valeur ; nouvelle tentative : mêmes valeur et corps. Facultatif pour vérification et heartbeat ; le SDK gère ses propres identifiants.

Tant que l’autorisation reste valide, les mêmes requêtes de validation et de heartbeat peuvent être réessayées pendant une heure sans double facturation. Passé ce délai, utilisez une nouvelle clé de requête ; une ancienne clé peut être considérée comme une nouvelle requête. L’activation, la désactivation et la consommation de fonctionnalités conservent des enregistrements d’idempotence durables.

Chaque activation, vérification, heartbeat ou déliage réussi consomme un appel API. Échecs et répétitions idempotentes ne sont pas recomptés ; CheckFeature reste local. Consume déduit les usages de la fonction, pas ce quota API ; quantity indique leur nombre.

Heartbeat, durée hors ligne et permanent suivent Politiques de licence.payload.expires_at indique l’expiration du cache signé actuel, pas celle de la licence. L’échéance finale figure dans les détails de la licence.