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 l'accès à l'API de production et le rate-limiting (HTTP 402 / 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.

Les deux périmètres sont étanches : une clé ne voit que les ressources de son environnement, en liste comme par identifiant, et ne peut pas bâtir une demande de signature sur un document de l'autre côté. Seuls les profils de marque, qui sont des réglages d'organisation, répondent aux deux. Voir Cloisonnement des environnements.

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 (402 payment_required, 403 forbidden, 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 — rate-limits par environnement et 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.