Embedded signing
Tokens d'embed, ouverture en popup et signal de complétion fiable pour intégrer la signature dans votre SaaS.
Statut de l'affichage en iframe. Les objets côté API existent et fonctionnent : le champ embed_src est bien renvoyé, l'endpoint POST /v1/submitters/{id}/embed_token émet bien un token valide et la liaison token vers slug est vérifiée au chargement. En revanche l'affichage de la page de signature dans une iframe n'est pas disponible actuellement. Le domaine sign.getinkr.eu renvoie X-Frame-Options: DENY et Content-Security-Policy: frame-ancestors 'none'. Une iframe restera donc vide.
Utilisez l'ouverture en popup décrite ci-dessous. Si l'iframe est un besoin bloquant pour votre intégration, contactez-nous.
Ce que renvoie l'API
À la création d'une submission, chaque submitter non pré-signé porte un champ embed_src :
{
"submitters": [
{
"id": "sbm_01J5HZ...",
"email": "alice@example.com",
"signing_url": "https://sign.getinkr.eu/s/abc123",
"embed_src": "https://sign.getinkr.eu/s/abc123?embed_token=eyJ..."
}
]
}| Champ | Usage |
|---|---|
signing_url | Lien public standard, à envoyer par email ou à ouvrir en popup. |
embed_src | Même lien porteur d'un token signé. TTL 24h par défaut. |
Ouvrir la signature en popup
const win = window.open(
submitter.signing_url,
'inkr-signature',
'width=900,height=1000',
)
// Le statut réel vient du webhook, pas de la fenêtre.
// Côté serveur, écoutez submission.completed puis notifiez votre front.La source de vérité est le webhook. Il n'existe aucun canal postMessage entre la page de signature et votre application : la page n'émet aucun message vers la fenêtre parente. Les events inkr:signed et inkr:declined que vous avez pu lire ailleurs n'existent pas. Le seul signal fiable de complétion est le webhook submission.completed ou, à défaut, un GET /v1/submissions/{id}.
Le paramètre redirect_url
Si vous fournissez redirect_url à la création, la page de signature navigue vers cette URL environ 3 secondes après la signature. C'est une redirection de la page de signature elle-même, utile pour ramener l'utilisateur dans votre application.
L'atterrissage sur votre redirect_url n'est pas une preuve de signature : l'utilisateur peut forger l'URL. Confirmez toujours côté serveur avant de débloquer quoi que ce soit.
Régénérer un embed_token
curl -X POST https://api.getinkr.eu/v1/submitters/sbm_01J5HZ.../embed_token \
-H "Authorization: Bearer $INKR_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "ttl_seconds": 3600 }'ttl_seconds est un entier entre 60 et 86400, avec 3600 par défaut. Le body entier est optionnel.
{
"embed_token": "eyJ...",
"expires_at": "2026-05-15T15:32:08.421Z",
"embed_url": "https://sign.getinkr.eu/s/abc123?embed_token=eyJ...",
"submitter_id": "sbm_01J5HZ..."
}Cette réponse expose embed_url. Le champ équivalent porté par un submitter dans une réponse submission s'appelle embed_src. Les deux contiennent la même chose.
Contenu et sécurité du token
Le token est signé en HMAC-SHA256 avec un secret applicatif. Sa charge utile contient l'identifiant du submitter, le slug de signature autorisé, les dates d'émission et d'expiration, un nonce anti-rejeu et un numéro de version. Aucune donnée personnelle n'y figure. Le slug porté par le token est comparé au slug de l'URL à chaque chargement, ce qui empêche de réutiliser un token pour un autre submitter.
Le slug est déjà le secret. La page /s/<slug> est publique et ne demande pas d'authentification : le slug lui-même tient lieu de secret. Le token d'embed est une restriction supplémentaire, pas le mécanisme d'accès. Traitez signing_url comme une donnée sensible, au même titre qu'un lien de réinitialisation de mot de passe.
Sur mobile
La signature dessinée fonctionne sur mobile mais l'expérience est nettement meilleure en pleine page qu'en fenêtre contrainte. Ouvrez signing_url en navigation standard plutôt qu'en popup réduite.