Des signatures depuis votre propre logiciel.

1. Étape 1

   Créer la demande

   Un POST /v1/signing-requests avec le PDF, les signataires et le placement des champs : anchors repère les marqueurs [[ls:signature:client]] dans le PDF, explicit prend des coordonnées, auto_append ajoute une page de signature. La réponse contient le documentId et une signingUrl par signataire.

   Dans la documentation

   curl https://api.wesign.now/v1/templates/$TEMPLATE_ID/instantiate \
     -H "Authorization: Bearer $WSK_KEY" \
     -H "Idempotency-Key: case-4711/mandate" \
     -H "Content-Type: application/json" \
     -d '{
       "recipients": [{ "slot": 1, "email": "anna@example.ch", "name": "Anna Muster" }],
       "field_values": { "company.legal_name": "Muster AG", "company.tax_id": "CHE-123.456.789" },
       "metadata": { "case_id": "4711" }
     }'

   Le même envoi depuis un modèle verrouillé : POST /v1/templates/{id}/instantiate fusionne vos field_values dans les {{placeholders}} et invite les destinataires.

2. Étape 2

   Votre signataire signe

   Nous envoyons l'invitation dans la langue du signataire depuis votre sous-domaine à votre marque — ou vous transmettez le lien vous-même avec send_emails: false. Ajoutez un numéro de mobile et require_sms_verification, et le signataire saisit d'abord un code à usage unique : une signature électronique avancée (AES) au lieu du niveau lien e-mail (SES).

   Dans la documentation

   "signers": [{
     "email": "anna@example.ch",
     "role": "client",
     "name": "Anna Muster",
     "locale": "de",
     "phone_e164": "+41791112233",
     "require_sms_verification": true
   }]
   
   # The invitation goes out in German from your branded subdomain.
   # Anna asks for the code on the signing page; the signature is AES once verified.
   # Deliver the link yourself instead: send_emails=false

3. Étape 3

   Vous recevez l'événement

   Enregistrez un webhook une fois pour l'espace de travail, ou passez callback_url par demande. Chaque livraison est signée HMAC-SHA256, réessayée avec backoff exponentiel et consignée dans un journal de livraison depuis lequel vous pouvez relivrer. document.completed arrive une fois par document avec signed_pdf_url, audit_trail_url et le sha256 du fichier.

   Dans la documentation

   POST https://your-app.example/wesign/callback
   X-WeSign-Event: document.completed
   X-WeSign-Signature: t=1757404800,v1=9c3b…a2f1
   
   {
     "event": "document.completed",
     "document_id": "8a1e4f9a-…",
     "metadata": { "case_id": "4711" },
     "signed_pdf_url": "https://api.wesign.now/v1/documents/8a1e4f9a-…/signed",
     "audit_trail_url": "https://api.wesign.now/v1/documents/8a1e4f9a-…/audit-trail",
     "sha256": "4f9a…d21c", …
   }

4. Étape 4

   Récupérer les fichiers

   GET /v1/documents/{id}/signed renvoie le PDF scellé PAdES, toutes les signatures sous un seul sceau ; /audit-trail rend le journal des événements — SHA-256, horodatage, IP masquées — en PDF, toujours en anglais. Les deux exigent votre clé. Comparez le hachage et conservez les deux fichiers chez vous.

   Dans la documentation

   curl -LOJ -H "Authorization: Bearer $WSK_KEY" \
     https://api.wesign.now/v1/documents/$DOC_ID/signed
   
   curl -OJ -H "Authorization: Bearer $WSK_KEY" \
     https://api.wesign.now/v1/documents/$DOC_ID/audit-trail
   
   # Compare the file's SHA-256 with the event's sha256, then store both files on your side.

Chaque réponse porte un X-Request-Id, et Paramètres → API conserve 30 jours un journal API de chaque appel — statut, code d'erreur, document concerné ; les corps ne sont jamais stockés. Une Idempotency-Key rend sûr un envoi ou un instantiate réessayé. Chaque clé peut effectuer 60 requêtes par minute.