Limites et rate-limits

Signlift applique deux mécanismes de limitation indépendants côté API :

• Un rate-limit par minute et par jour, scopé par organisation.
• Un quota mensuel de signature requests, scopé par plan.

Les deux mécanismes renvoient des codes HTTP différents et ne se comportent pas de la même manière côté retry — distinguez-les avant de coder un client robuste.

Rate-limits API par plan

Le rate-limit s'applique à toutes les routes /api/v1/* et est compté par organisation : si vous avez plusieurs clés API actives sur la même organisation, elles partagent le compteur.

En dépassement, Signlift répond 429 rate_limited avec les headers standards :

HTTP/1.1 429 Too Many Requests
Retry-After: 42
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1764800042
Content-Type: application/json

{ "error": { "code": "rate_limited", "message": "..." } }

Quota mensuel de signature requests

Indépendamment du rate-limit, chaque plan inclut un nombre maximal de signature requests créées par mois. Le quota est vérifié au moment du POST /api/v1/signature_requests.

En dépassement, Signlift répond 403 quota_exceeded :

{
  "error": {
    "code": "quota_exceeded",
    "message": "..."
  }
}

Contrairement au rate-limit, ce code ne porte pas de header Retry-After : le quota se réinitialise au début du mois calendaire suivant. Le retry automatique côté client n'a aucun sens ici — il faut soit attendre le mois suivant, soit upgrader le plan.

Stratégies côté client

Sur 429 rate_limited

• Lisez Retry-After, ne hardcodez pas un délai arbitraire.
• Appliquez un exponential backoff avec jitter pour les retries successifs si vous orchestrez plusieurs appels en parallèle : 1 s, 2 s, 4 s, 8 s, plafonné à 60 s, plus une perturbation aléatoire de ±20 % pour éviter le thundering herd.
• Sérialisez les appels non-critiques dans un job queue côté backend plutôt que de saturer la fenêtre minute.

Sur 403 quota_exceeded

• Ne retentez pas automatiquement. Capturez l'erreur, alertez votre équipe.
• Surveillez votre consommation depuis le dashboard Signlift pour anticiper le seuil.
• Si vous êtes proche du plafond chaque mois : upgrade du plan ou re-architecture du flux côté votre app (ex : regrouper plusieurs documents par signature request).

Pour toutes les écritures (POST)

• Capturez et persistez l'id retourné par Signlift dès la première réponse réussie. En cas de retry réseau, vérifiez son existence côté Signlift (GET /api/v1/signature_requests/:id) avant de réémettre — l'API ne déduplique pas côté serveur.

Limites adjacentes

Ces limites ne concernent pas l'API publique mais peuvent affecter votre intégration globale :

• OTP signataire — 5 tentatives sur 10 minutes par token. Au-delà, le code est invalidé et un nouveau doit être émis. Concerne le parcours signataire (page /sign/:token), pas vos appels API.
• Renvoi d'invitation membre — 3 par membre / 10 min, 30 par IP / heure. Concerne le dashboard d'organisation, pas l'API.

Aller plus loin

• Authentification — clés API, JWT signataires.
• Référence API — table complète des codes d'erreur.
• Tarifs — détail des plans et quotas.