Vue d'ensemble

URL de base

L'API Signlift v1 est exposée sur une URL unique :

https://app.signlift.eu/api/v1

Pas de host dédié à la sandbox — l'environnement (sandbox ou production) est porté par votre application externe, donc par votre clé API. Voir Authentification.

Toutes les ressources sont versionnées sous /api/v1. Une future v2 sera servie sous /api/v2 en parallèle ; aucun breaking change sur v1 sans préavis de 6 mois minimum.

Authentification

Toutes les requêtes nécessitent un header X-Api-Key. Voir Authentification.

Format des erreurs

Toutes les erreurs suivent ce schéma :

{
  "error": {
    "code": "validation_error",
    "message": "Validity days must be between 1 and 90"
  }
}

HTTP	Code	Signification
401	`invalid_api_key`	Clé absente, mal formée ou révoquée.
402	`payment_required`	API de production réservée aux plans payants. Passez au plan Pro, ou contactez-nous pour un plan Enterprise.
403	`forbidden`	Pas les droits sur cette ressource.
403	`initials_not_available_on_plan`	`initials_required: true` envoyé sur un plan Free. Réservé Pro / Enterprise.
404	`not_found`	ID inexistant ou inaccessible (toutes les routes sont scopées à votre organisation).
422	`identity_declaration_required`	`send_email: true` sans `identity_declaration_accepted`. Cf. Signature Requests.
422	`validation_error`	Échec de validation du payload, pour tout échec qui ne porte pas de code plus précis.
429	`rate_limited`	Cf. headers `Retry-After` / `X-RateLimit-*`.

Voir Limites et rate-limits pour la mécanique des 402 / 429.

Le quota mensuel d'envois ne s'applique pas à l'API : il ne concerne que les envois créés depuis l'interface. POST /api/v1/signature_requests ne renvoie donc jamais d'erreur de quota, quel que soit votre plan. Voir Quota mensuel des envois interface.

Format de date

Toutes les dates sont ISO 8601 en UTC (2026-05-17T15:00:00Z). Les champs suffixés _at sont des timestamps datetime.

Format des identifiants

Les identifiants exposés par l'API sont des entiers (42, 1768). Ils sont uniques au sein d'une ressource mais ne sont pas garantis stables entre environnements (un même id ne désigne pas la même ressource entre sandbox et production).

Collections paginées

Quatre endpoints rendent une collection. Tous portent la même enveloppe :

{
  "data": [],
  "pagination": { "page": 1, "limit": 20, "count": 137, "pages": 7 }
}

count est le total sur l'ensemble des pages, pages le nombre de pages pour la limit demandée.

Pagination

Paramètre	Défaut	Comportement
`page`	`1`	Plafonné. Une valeur absente, négative ou non numérique retombe sur le défaut.
`limit`	`20`	Plafonné à 100. Au-delà, la valeur est ramenée au plafond, pas rejetée.

Les deux plafonds sont silencieux : la réponse renvoie dans pagination la valeur réellement appliquée. Lisez-la plutôt que de supposer que la vôtre a été retenue.

Filtres

Deux collections acceptent des filtres : les demandes de signature et les documents.

Paramètre	Valeurs
`status`	l'énumération de la ressource
`created_after`	date ou horodatage ISO 8601
`created_before`	date ou horodatage ISO 8601
`order`	`asc` (défaut) / `desc`

Contrairement à page et limit, les filtres sont stricts : une valeur illisible renvoie 422 validation_error au lieu d'être ignorée. Un filtre ignoré en silence rendrait une collection fausse qui a l'air juste.

created_after et created_before sont des bornes inclusives. Une date nue désigne la journée entière : en borne basse elle vaut minuit, en borne haute la fin de journée, de sorte que created_before=2026-05-17 conserve bien tout le 17 mai.

Cloisonnement des environnements

Toute lecture et toute écriture sont restreintes à l'environnement de la clé appelante. Une clé sandbox ne voit que les ressources sandbox, une clé production que les production — en liste comme en lecture unitaire par identifiant.

Au-delà de cette frontière, l'API répond 404 not_found, jamais 403 : la ressource n'existe pas pour cette clé. Une demande de signature ne peut pas davantage être construite à partir d'un document de l'autre environnement — POST /api/v1/signature_requests répond alors 422 validation_error.

Les documents téléversés depuis l'interface web sont du côté production, comme les demandes qui en sortent. Les profils de marque font exception : ce sont des réglages d'organisation, visibles des deux côtés.

Versionning et stabilité

Les nouveaux champs ajoutés à une réponse sont considérés comme rétrocompatibles. Votre client doit ignorer les champs qu'il ne connaît pas.
Les changements breaking (suppression d'un champ, renommage, changement de type) sont annoncés au moins 6 mois à l'avance et accompagnés d'une nouvelle version v2.

Vue d'ensemble

On this page