Authentification

Signlift expose deux mécanismes d'authentification distincts, à ne pas confondre :

• Clés API — utilisées par votre backend pour appeler les endpoints /api/v1/*.
• URLs de signature — émises par Signlift et transmises à chaque signataire pour ouvrir la page /sign/:token, y compris en iframe embedding.

Pour les quotas et le rate-limiting (HTTP 403 / 429), voir Limites et rate-limits.

Clés API

Toutes les requêtes serveur-vers-Signlift se font sur https://app.signlift.eu et portent le header X-Api-Key.

curl https://app.signlift.eu/api/v1/signature_requests \
  -H "X-Api-Key: $SIGNLIFT_API_KEY"

Format

Une clé API est une chaîne hexadécimale de 64 caractères, sans préfixe. Elle est affichée une seule fois au moment de la création — Signlift ne la stocke pas en clair côté serveur (seul un hash SHA-256 est persisté), il n'est donc pas possible de la récupérer ensuite.

a3f9b1c8...d4e2          # 64 chars hex

Sandbox et production

Chaque clé est rattachée à une application externe, elle-même rattachée à une organisation et à un environnement (sandbox ou production).

L'environnement est porté par l'application externe — il n'apparaît pas dans la clé elle-même, et il n'y a pas de host dédié à la sandbox. Vous appelez toujours https://app.signlift.eu, le comportement est conditionné par la clé envoyée.

Pour passer en prod : créez une seconde application externe en environnement production. Il n'y a pas de promotion d'une clé sandbox.

Émission, rotation et révocation

• Émission : depuis le dashboard, Paramètres → Applications externes → Nouvelle application. La clé brute et le webhook_secret sont affichés une seule fois.
• Rotation sans downtime : créez une nouvelle application, déployez-la, puis révoquez l'ancienne. Les deux clés coexistent tant que la première n'a pas été révoquée. Recommandation : tous les 90 jours.
• Révocation : un clic dans le dashboard. Côté serveur, le champ revoked_at est positionné — la clé devient immédiatement non-acceptée.
• last_used_at : mis à jour à chaque appel authentifié. Utile pour repérer une clé dormante avant rotation.

URLs de signature

À la création d'une signature request, l'API retourne pour chaque signataire un champ signing_url — une URL absolue prête à l'emploi qui ouvre la page de signature Signlift.

{
  "id": 42,
  "status": "pending",
  "signers": [
    {
      "id": 1768,
      "email": "jeanne@example.com",
      "status": "pending",
      "signing_url": "https://app.signlift.eu/sign/eyJhbGciOiJIUzI1NiJ9..."
    }
  ]
}

Vous transmettez cette URL telle quelle au signataire — par e-mail, redirect HTTP, ou comme src d'iframe. Aucune manipulation requise côté client.

• L'URL est valable jusqu'à expiration de la signature request (paramètre validity_days, 1 à 90 jours).
• Une fois le signataire a signé, signing_url devient null dans les lectures suivantes.
• Chaque signataire a son URL unique — ne les partagez pas entre signataires.

Pour le pattern complet d'embedding, voir Intégration iframe.

Erreurs d'authentification

Une seule erreur est spécifique à l'authentification API :

Les autres codes (403 forbidden, 403 quota_exceeded, 429 rate_limited, 422 validation_error, 404 not_found) ne sont pas liés à l'authentification — voir Limites et rate-limits et la référence API.

Aller plus loin

• Limites et rate-limits — quotas par plan, headers Retry-After.
• Webhooks — la signature HMAC est un mécanisme distinct, propre aux webhooks.
• Intégration iframe — usage complet de signing_url.