Concevoir des intégrations d'API SMM qui survivent aux pannes

La première version de toute intégration d'API suppose le chemin idéal : vous envoyez une requête, vous obtenez une réponse, la commande est passée. La production vous apprend le contraire. Les réseaux tombent, les points d'accès expirent, et l'échec le plus dangereux est celui qui est ambigu, la requête qui a pu réussir ou non avant que la connexion ne meure. Concevoir pour cette ambiguïté, c'est tout le travail.

L'idempotence est la défense centrale. Attachez une clé unique à chaque requête de commande et faites en sorte que le serveur traite la répétition de cette clé comme la même opération, et non comme une nouvelle. Désormais, une nouvelle tentative après un délai d'expiration est sûre : si l'originale est passée, vous récupérez la commande existante au lieu d'un double prélèvement. Sans cela, chaque nouvelle tentative est un pari avec votre solde.

Superposez par-dessus des nouvelles tentatives avec backoff. Les erreurs transitoires (une limite de débit 429, une 503, une réinitialisation réseau) doivent être réessayées avec des délais croissants et un plafond, et non martelées instantanément. Les erreurs permanentes (une requête incorrecte 400, une réponse de solde insuffisant) doivent échouer rapidement et remonter à un humain, car les réessayer ne fait que gaspiller du temps et masquer le vrai problème.

Enfin, réconciliez. Journalisez chaque requête et réponse avec sa clé d'idempotence et son identifiant de commande, et exécutez une tâche périodique qui compare vos enregistrements aux états de commande du panel. La réconciliation est ce qui rattrape la commande qui a réussi sur le panel mais n'a pas été enregistrée de votre côté. L'API de SocialGO renvoie des identifiants et des états de commande cohérents spécifiquement pour que cette boucle soit simple à construire : la différence entre une automatisation à laquelle vous faites confiance et une automatisation que vous devez surveiller.