Idempotence
Rejouer une écriture sans risque de la faire deux fois, avec l'en-tête Idempotency-Key.
Un réseau coupe, une réponse se perd : votre programme ne sait pas si l'écriture a eu lieu. Avec une Idempotency-Key, il la renvoie sans risque : Lidmeo ne la refait pas, il rend la même réponse.
curl https://api.lidmeo.com/v1/prospects/pros_…/approve_invitation \
-X POST \
-H "Authorization: Bearer $LIDMEO_API_KEY" \
-H "Idempotency-Key: approve-pros_1Hq3ZtV9kWmA-2026-10-01"- Sur toute écriture :
POST,PUT,PATCH,DELETE. Une lecture n'en a pas besoin. - La clé : de 1 à 255 caractères, lettres, chiffres et
. _ : -. Un identifiant aléatoire (UUID) par opération convient très bien. - 24 heures : une clé est gardée 24 heures, pour la clé d'API ou la connexion qui l'a envoyée, et pour ce compte.
Ce qui se passe
| Situation | Réponse |
|---|---|
| Clé neuve | L'action a lieu. |
| Même clé, même requête, action terminée | La réponse d'origine, rejouée, avec les en-têtes Idempotent-Replayed: true et Original-Request (l'identifiant de la requête d'origine, que le corps garde dans request_id) ; Request-Id est celui de la requête qui rejoue. Rien n'est refait. |
| Même clé, action encore en cours | 409 idempotency_key_in_use : réessayez dans un instant. |
| Même clé, autre requête (autre corps, autre chemin) | 422 idempotency_key_mismatch : une clé sert à une seule opération. |
| Même clé, réponse d'origine illisible | 409 conflict : rien n'est refait ; recommencez avec une nouvelle clé. |
Une réponse qui dit ce qui s'est passé est gardée, refus compris. Un envoi qui a atteint LinkedIn puis échoué (502 send_failed) l'est aussi : la même clé rejoue ce refus, elle ne renvoie jamais. Ne sont pas gardés les autres 5xx (le plus souvent une panne avant toute action) ni les refus passagers (409 import_in_progress, 409 send_in_progress…) : la même clé peut alors être reprise, et l'action est refaite. Après un 5xx sur une écriture, relisez l'objet avant de reprendre : une écriture en plusieurs temps peut avoir été appliquée en partie (applied le dit).
Les réponses gardées sont chiffrées.
Les SDK le font pour vous
Chaque écriture des SDK porte une clé, la même à chaque nouvelle tentative : une écriture reprise après une coupure n'est jamais faite deux fois. Donnez la vôtre pour la relier à votre propre opération :
await lidmeo.prospects.approveInvitation("pros_…", { idempotencyKey: "commande-4521" });Les envois ont aussi leurs propres gardes
Même sans clé, Lidmeo n'envoie jamais deux fois la même invitation ni le même premier message : la seconde demande répond que c'est déjà fait, ou que l'état du prospect ne le permet plus. La clé vous rend en plus la même réponse, mot pour mot.