Erreurs, débit et mise en production Click&Cert
Gérer les refus, les reprises et les résultats incertains dans une intégration robuste.
Le débit de l’API Click&Cert est rattaché à l’organisation et à son abonnement. Il ne se multiplie pas en ouvrant plusieurs connexions ou en utilisant plusieurs certificats. Dimensionnez la file de travaux selon le plafond activé et l’offre souscrite.
Réponses v1
| Statut | Exemple | Action |
|---|---|---|
200 | Résultat créé | Décoder, valider et conserver |
401 | Authentification Basic absente ou invalide | Vérifier les accès et l’environnement |
403 | Abonnement inactif ou utilisation de certificat non autorisée | Vérifier abonnement et habilitations |
422 | Données de requête invalides, certificat indisponible ou option non prise en charge | Corriger la cause avant de relancer |
429 | Too Many Requests | Réduire le débit et temporiser |
500 | SigningError | Enregistrer l’incident, évaluer l’état de l’opération et contacter le support si nécessaire |
La validation de requête utilise généralement message et errors. Les erreurs métier utilisent error et message, notamment CertificateUnavailableException, UnsupportedSignatureOptionException et les erreurs TOTP. Les contrats legacy ont leurs propres noms et formes d’erreur ; ne leur appliquez pas un parseur v1 sans adaptation.
Exemple d’erreur métier
{
"error": "CertificateUnavailableException",
"message": "Certificate unavailable."
}Un 422 peut aussi signaler un Base64 vide ou invalide, un digest de mauvaise longueur, un profil non disponible pour ce format ou un rectangle visible hors de la page. Le champ errors permet d’identifier les paramètres concernés lorsqu’il s’agit d’une validation de requête.
Concurrence et reprise
Utilisez une file, un nombre de traitements simultanés maîtrisé et une temporisation progressive avec variation aléatoire après limitation. Respectez Retry-After lorsqu’il est présent. Une option Premium peut nécessiter une modification du plafond activé ; ne supposez pas que la souscription est propagée instantanément à tous les environnements.
Les endpoints de création ne documentent pas de clé d’idempotence. Un timeout ou une réponse perdue ne prouve pas qu’aucune signature n’a été produite. Enregistrez un état incertain et décidez d’une reprise avec votre règle métier. Une nouvelle requête peut produire une autre signature et une nouvelle consommation.
signature_uid est une référence de résultat, pas une promesse d’API de récupération ultérieure. Archivez les octets retournés dès réception. N’attendez pas qu’un lien de téléchargement non documenté apparaisse.
Recette avant production
Vérifiez l’accès standard et les options souscrites, les habilitations de chaque certificat, le renouvellement, les erreurs attendues et les formats réellement consommés par vos destinataires. Pour les PDF, testez pages tournées, champs, signatures existantes et placement visible. Pour le mode digest, validez l’assemblage final et les données détachées.
Une recette fonctionnelle avec des certificats de test ne démontre pas la qualification de production. Vérifiez séparément le statut, le certificat et le périmètre du service de production.
Journalisation et assistance
Conservez référence métier, signature_uid, UID du certificat, format, profil, environnement, statut, durée et empreinte du résultat. Excluez secrets, codes TOTP et contenu des documents des journaux ordinaires. Pour le support, fournissez un contexte expurgé et l’heure avec fuseau.
Consultez la page de statut Datasure. Les engagements de disponibilité, latence éventuelle, assistance et indemnisation restent ceux de votre contrat.
Updated about 2 hours ago

