Prérequis
- Un compte Firma avec une clé API
- Une clé API OpenAI (pour le function calling), ou un compte ChatGPT Plus/Pro/Enterprise (pour la CLI Codex et les connecteurs)
- Au moins un Modèle Firma avec des Champs de signature configurés
Firma utilise la clé API brute comme valeur de l’en-tête
Authorization - ne la préfixez pas avec Bearer. Cela diffère de l’API OpenAI elle-même, qui utilise des jetons Bearer.Pour commencer
- Function calling
- Codex CLI via MCP
- Connecteurs ChatGPT
Le function calling permet à un modèle GPT de décider quand appeler votre code. Vous déclarez une fonction que le modèle peut appeler, et lorsque l’utilisateur lui demande d’envoyer un contrat, le modèle renvoie un appel d’outil structuré que votre application exécute contre l’API Firma.Cette approche convient parfaitement aux agents IA, chatbots, et à toute application où une demande utilisateur en langage naturel doit se transformer en Demande de Signature.Un message utilisateur comme « Envoie le contrat de conseil à alice@acme.com » déclenchera l’appel de fonction.
Étape 1 : Stockez vos clés API
Conservez votre clé API OpenAI et votre clé API Firma dans des variables d’environnement. Ne les placez jamais dans du code frontend.Étape 2 : Déclarez une fonction et gérez les appels d’outils
Avec la Responses API d’OpenAI (recommandée pour les nouveaux projets) :Le endpoint
create-and-send crée la Demande de Signature et l’envoie aux Destinataires en un seul appel API. Si vous voulez que le modèle rédige une demande pour révision avant l’envoi, utilisez POST /signing-requests pour créer un brouillon, puis POST /signing-requests/{id}/send une fois approuvé.Étape 3 : Intégrez-le dans votre application
AppelezhandleUserMessage depuis votre backend chaque fois que l’utilisateur envoie un message de chat :Alternative Python
Le même flux avec le SDK Python :Intégration webhook
Pour suivre les événements de signature en temps réel, enregistrez un Webhook Firma pointant vers un endpoint de votre application :Signature intégrée
Pour les applications où les Signataires complètent les documents directement dans votre interface plutôt que d’ouvrir une page hébergée par Firma, la réponse decreate-and-send inclut first_signer.id (le signing_request_user_id) et un first_signer.signing_link prêt à l’emploi. Chargez l’URL du Signataire dans une iframe :
Astuces
- Utilisez le function calling pour les agents en exécution, MCP pour la construction. Le function calling est ce que votre application déployée utilise pour envoyer des documents. Les serveurs MCP sont ce que vous et la CLI Codex utilisez pour construire cette intégration.
- Passez
template_idcomme argument d’outil, pas comme chaîne libre. Les Modèles sont le moyen le plus sûr de limiter ce que le modèle peut envoyer. - Validez avant d’envoyer. Pour les documents à enjeux plus élevés, utilisez
POST /signing-requestspour créer un brouillon, présentez-le à l’utilisateur, puis appelezPOST /signing-requests/{id}/sendseulement après leur confirmation. - Espaces de Travail pour les applications multi-tenant. Si vous construisez un produit SaaS au-dessus de l’API OpenAI, donnez à chaque client final son propre Espace de Travail Firma afin que les Modèles et l’utilisation restent isolés.
Prochaines étapes
- Authentification API - Clés API et portée des Espaces de Travail
- Guide des webhooks - Types d’événements, payloads et vérification de signature
- Signature intégrée - Expérience de signature intégrée à l’application
- Création d’Espaces de Travail - Configurations multi-tenant pour les applications SaaS
- Intégration MCP - Référence complète du serveur MCP avec les 84 outils
- Guide de configuration complet - Parcours d’intégration Firma de bout en bout
- Référence API - Documentation complète des endpoints