Si vous publiez par programmation, deux limites de débit distinctes s’appliquent, et une seule est sous votre contrôle.
Les deux niveaux
La limite de la plateforme. Chaque réseau social limite ce qu’une application peut faire sur son API, avec sa propre fenêtre, ses propres en-têtes et son propre comportement en cas de dépassement. Elles diffèrent d’une plateforme à l’autre et changent sans grand préavis.
La limite de votre fournisseur. Si vous publiez via une API unifiée, ce service a lui aussi une limite, généralement liée à votre plan.
La seconde est facile à lire et à anticiper. La première est celle qui mord, car vous ne la voyez jamais directement si vous utilisez une API unifiée. Le fournisseur l’absorbe, ce qui est une grande partie de ce que vous payez, mais elle ne disparaît pas : une plateforme qui limite tout le monde signifie quand même que votre publication est retardée.
Concevoir pour le délai, pas seulement pour les erreurs
L’erreur la plus courante dans un pipeline de publication est de traiter « accepté » comme « publié ».
Sur plusieurs plateformes, soumettre une publication renvoie un succès et la publication réelle a lieu ensuite. L’échec arrive donc plus tard, hors bande, longtemps après que votre requête a renvoyé 200. Si votre modèle de données n’a que « envoyé » et « échoué », il n’y a nulle part où placer « nous pensons que c’est en cours de publication ».
Concevez pour trois états, et rendez visible celui qui est en attente.
Règles pratiques
Reculez de façon exponentielle. Sur un 429, attendez et réessayez avec un délai croissant. Les nouvelles tentatives immédiates aggravent la situation et peuvent prolonger une limitation.
Plafonnez vos tentatives. Un pipeline qui réessaie indéfiniment, c’est ainsi qu’un quota disparaît en quelques minutes. Abandonnez, journalisez bruyamment, et laissez un humain regarder.
Ne réessayez jamais une création à l’aveugle. Si une requête de création expire, vous ne savez pas si elle a réussi. Réessayer peut produire des publications en double, ce qui est pire que l’échec initial. Vérifiez avant de réessayer, ou utilisez une approche qui rend la nouvelle tentative sûre.
Regroupez quand un point de terminaison le permet. Une requête créant plusieurs publications coûte une requête. Le même travail en cinquante appels individuels coûte cinquante requêtes.
Les propres limites de BulkPublish
| Free | Pro | Business | |
|---|---|---|---|
| Requêtes API/jour | 30 | 5 000 | 50 000 |
| Clés API | 1 | 5 | 10 |
| Publications | 3/jour | 30/jour | Illimité |
Les 30 requêtes par jour du palier gratuit sont délibérément dimensionnées pour évaluer l’API et faire tourner quelque chose de léger et personnel. Ce n’est pas suffisant pour faire tourner un vrai pipeline, et une boucle sans backoff l’épuisera en quelques secondes.
Notez que les requêtes API et les publications sont des limites séparées. Lister les canaux, vérifier le statut et téléverser des médias consomment tous des requêtes sans créer de publication, si bien que le budget de requêtes va plus loin que ne le suggère le nombre de publications, mais seulement si vous l’utilisez avec soin.
Plusieurs clés servent à la séparation, pas à plus de capacité
Les plans payants incluent plusieurs clés API, et la raison n’est pas un débit supplémentaire. C’est pour que des choses différentes détiennent des identifiants différents : votre pipeline de production, un environnement de préproduction, un agent IA.
La valeur apparaît quand quelque chose tourne mal. Vous révoquez une clé à 2 h du matin plutôt que de faire tourner l’identifiant unique que tout partage.
Une forme sensée pour une tâche de publication
- Récupérez les canaux une fois au démarrage, pas par publication
- Téléversez les médias, puis créez les publications en référençant les identifiants
- Utilisez les points de terminaison de traitement par lot là où ils existent
- Gérez le 429 avec un backoff exponentiel et un plafond de tentatives
- Journalisez chaque échec avec le corps de la réponse, car personne ne surveille
En résumé
Deux limites s’appliquent : celle de la plateforme, que vous ne pouvez pas voir à travers une API unifiée, et celle de votre fournisseur, que vous pouvez voir. Reculez de façon exponentielle, plafonnez les tentatives, ne réessayez jamais une création à l’aveugle, regroupez quand vous le pouvez. Et traitez « accepté » comme un état distinct de « publié », car sur plusieurs plateformes, c’est réellement le cas.