Éditeur de demande de signature intégrable
Intégrez l’éditeur de demande de signature de Firma dans votre application grâce à une authentification JWT pour un accès sécurisé et limité dans le temps. C’est idéal pour les intégrations en marque blanche et les applications multi-tenant.Cas d’usage
- Flux de signature en marque blanche : gérez les demandes de signature sous votre propre marque
- Applications multi-tenant : accès sécurisé par signataire sans exposer vos clés API
- Flux documentaires intégrés : gestion fluide des demandes de signature au sein de votre produit
- Accès limité dans le temps : les jetons expirent automatiquement pour plus de sécurité (expiration à 7 jours)
Fonctionnement
- Votre serveur demande un jeton JWT à l’API de Firma en utilisant votre clé API
- Firma renvoie un jeton JWT de courte durée contenant l’identifiant de la demande de signature
- Votre frontend intègre l’éditeur avec le jeton JWT
- Le jeton expire automatiquement après 7 jours
Limite de débit : les endpoints JWT prennent en charge 100 requêtes par minute et par clé API pour les applications à fort volume.
Authentification JWT
Générer un jeton JWT
Générez un jeton JWT pour une demande de signature spécifique à l’aide de l’endpoint/jwt/generate-signing-request.
Endpoint : POST /jwt/generate-signing-request
Corps de la requête :
Guide d’implémentation
Backend : générer un jeton JWT
Appelez l’API Firma depuis votre backend pour générer un jeton JWT. Votre endpoint backend doit accepter un identifiant de demande de signature et renvoyer le JWT à votre frontend. Exemple Node.js :Implémentation frontend — HTML / JavaScript natif
Implémentation frontend — React
Options de configuration
Méthodes d’instance
Utilisez
triggerClose() lorsque votre application hôte doit fermer l’éditeur depuis sa propre interface, par exemple lors d’un événement de navigation parent ou d’un bouton « retour » :
Événements postMessage (éditeur → hôte)
L’éditeur de demande de signature de Firma émet des événements postMessage pour les actions clés du cycle de vie. Voici un schéma d’événements minimal recommandé que vous pouvez implémenter pour réagir aux enregistrements et envois depuis l’éditeur. Enveloppe de l’événement (charge utile de window.postMessage) :Exemple d’écouteur côté client (JS pur)
Gestion du cycle de vie des jetons
Les jetons JWT sont générés avec une durée d’expiration de 7 jours pour les flux d’édition classiques. L’éditeur gère automatiquement l’expiration du jeton.Expiration automatique
Les jetons JWT expirent automatiquement après 7 jours, en fonction du timestampexpires_at. Après expiration :
- L’éditeur intégré rejette le jeton
- Un nouveau jeton doit être demandé pour continuer
- Aucun appel API n’est nécessaire, les jetons expirent passivement
Rafraîchissement du jeton (optionnel)
Pour les sessions d’édition de longue durée, vous pouvez rafraîchir le jeton avant son expiration à l’aide de la méthodeupdateJWT() :
Limite de débit
Les endpoints JWT prennent en charge 100 requêtes par minute et par clé API. En-têtes de limite de débit :- Mettez en cache les jetons et réutilisez-les jusqu’à leur expiration (7 jours)
- Implémentez un backoff exponentiel pour les nouvelles tentatives
- Surveillez l’en-tête
X-RateLimit-Remaining - Générez les jetons à la demande, pas de manière anticipée
Bonnes pratiques de sécurité
✅ À faire
- ✅ Générez les jetons depuis votre serveur backend
- ✅ Surveillez les limites de débit (100 requêtes/minute)
- ✅ Utilisez HTTPS pour toutes les requêtes API
- ✅ Utilisez
readOnly: truepour un accès en lecture seule
❌ À ne pas faire
- ❌ N’exposez pas les clés API dans le code frontend
- ❌ Ne réutilisez pas les jetons entre plusieurs sessions ou signataires
- ❌ Ne journalisez pas les jetons JWT (risque de sécurité)
- ❌ Ne partagez pas les jetons entre différentes demandes de signature
Dépannage
Erreur de jeton expiré
Symptôme : l’éditeur affiche « Token expired » ou une erreur d’authentification Solution :- Implémentez un rafraîchissement du jeton avant expiration (fenêtre de 7 jours)
- Générez un nouveau jeton et appelez
editor.updateJWT(newToken) - Vérifiez la synchronisation de l’horloge système
401 Unauthorized
Symptôme : la génération du JWT échoue avec une erreur 401 Causes possibles :- Clé API invalide ou manquante
- La clé API ne dispose pas des permissions requises
- La clé API est désactivée
404 Not Found
Symptôme : la demande de signature est introuvable lors de la génération du JWT Causes possibles :- L’identifiant de la demande de signature n’existe pas
- La demande de signature appartient à un autre espace de travail
- La demande de signature a été supprimée
Limite de débit dépassée
Symptôme : 429 Too Many Requests Solution :- Implémentez une mise en cache des jetons (la fenêtre d’expiration de 7 jours est généreuse)
- Attendez la réinitialisation de la limite de débit (vérifiez l’en-tête
X-RateLimit-Reset) - Implémentez une logique de nouvelle tentative avec backoff exponentiel
L’éditeur ne se charge pas
Symptôme : le conteneur est vide ou affiche un indicateur de chargement indéfiniment Causes possibles :- Le script n’est pas chargé (vérifiez l’événement
script.onload) - JWT ou identifiant de demande de signature invalide
- Problèmes CORS (vérifiez la console du navigateur)
- Vérifiez que le script est chargé depuis
https://app.firma.dev/embed/signing-request-editor.js - Vérifiez que le JWT est valide et non expiré
- Assurez-vous que le backend renvoie les en-têtes CORS corrects
Étapes suivantes
- Intégrer l’éditeur de modèles pour la création de modèles en marque blanche (120 req/min)
- Envoyer des demandes de signature par programmation (100 req/min)
- Configurer des webhooks pour suivre les événements de demande de signature (60 req/min)
- Configurer les paramètres de l’espace de travail pour les applications multi-tenant (100-200 req/min)