Vue d'ensemble
URL de base, format des erreurs et conventions de l'API Signlift v1.
URL de base
L'API Signlift v1 est exposée sur une URL unique :
https://app.signlift.eu/api/v1Pas 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. |
| 403 | forbidden | Pas les droits sur cette ressource. |
| 403 | quota_exceeded | Quota mensuel de signature requests dépassé. |
| 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 | validation_error | Échec de validation du payload (catch-all pour la majorité des erreurs métier). |
| 429 | rate_limited | Cf. headers Retry-After / X-RateLimit-*. |
Voir Limites et rate-limits pour la mécanique des 403 quota / 429 rate-limit.
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).
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.