Planifier des posts avec une API : X, LinkedIn et Bluesky en un seul appel

Si vous ajoutez la planification à un produit (un CMS, un outil de newsletter, un assistant de contenu), vous verrez vite que chaque réseau s’y prend autrement. Certains proposent une planification native très limitée, d’autres aucune. Et chacun a son authentification, ses plafonds et ses façons d’échouer.

La voie classique : stocker le post, lancer une tâche au bon moment, appeler chaque API. Vous devenez alors responsable du planificateur, de la politique de relance, du rafraîchissement des tokens et des erreurs affichées à l’utilisateur.

Il y a plus court.

La version en une requête

curl -X POST https://hapi.tools/v1/posts \
  -H "Authorization: Bearer $HAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: campaign-42-post-1" \
  -d '{
    "content": "Our winter release is live. Here is what is new 👇",
    "platforms": ["x", "linkedin", "bluesky"],
    "scheduledAt": "2026-12-01T09:00:00-03:00",
    "timezone": "America/Sao_Paulo"
  }'

Ce qui se passe :

1. Hapi valide le contenu contre les limites réelles de chaque plateforme avant de l’accepter. Si le texte est trop long pour Bluesky ou X, vous avez l’erreur tout de suite, pas un post en échec à 9 h.
2. Le post est enregistré pour cet instant précis, avec le fuseau horaire dans lequel il a été prévu.
3. Au moment de publier, Hapi rafraîchit les tokens si besoin, publie sur chaque compte et conserve un résultat par compte.
4. Votre endpoint de webhook reçoit un événement signé post.published ou post.failed pour chaque résultat.

Des fuseaux horaires qui ne se trompent pas d’heure

Envoyez toujours scheduledAt en ISO 8601 avec un décalage (2026-12-01T09:00:00-03:00) ou en UTC (2026-12-01T12:00:00Z). Une heure sans décalage est refusée : un post ne peut pas partir à la mauvaise heure à cause de l’horloge du serveur. Ajoutez un fuseau IANA, par exemple America/Sao_Paulo, pour garder la trace de l’heure locale prévue.

Laissez une bibliothèque de dates calculer le décalage, changements d’heure compris. Avec Luxon : DateTime.fromISO("2026-12-01T09:00", { zone: "America/Sao_Paulo" }).toISO() renvoie 2026-12-01T09:00:00.000-03:00, que Hapi accepte tel quel.

Un texte différent par réseau

LinkedIn récompense les textes longs, Bluesky s’arrête à 300 caractères, et X a ses propres limites. platformOptions permet d’adapter chaque version dans la même requête :

"platformOptions": {
  "linkedin": { "content": "Our winter release is live.\n\nThree things our customers asked for most: ..." },
  "bluesky": { "content": "Winter release is live ❄️ hapi.tools/changelog" }
}

Savoir quand ça échoue

Dans beaucoup d’outils maison, une publication planifiée échoue en silence. Hapi signe chaque webhook en HMAC-SHA256 et relance la livraison avec un backoff exponentiel (jusqu’à 6 tentatives) :

hapi-signature: t=1764590400,v1=5f2b...

Vérifiez la signature, puis prévenez tout de suite : « Votre post LinkedIn n’est pas parti, le compte a été déconnecté. Le reconnecter ? »

Décaler ou annuler

Un post planifié est une ressource comme une autre. Récupérez-le, modifiez scheduledAt, ou supprimez-le via /v1/posts/{id}. Le tableau de bord Hapi propose aussi un calendrier en glisser-déposer, si l’équipe préfère les gérer à la main.

Quelles plateformes sont en production

Aujourd’hui, la planification et la publication sont en production sur X, LinkedIn, Bluesky, Telegram, Discord et Slack. Instagram, TikTok, YouTube, Threads, Facebook, Pinterest et d’autres sont disponibles en mode sandbox : la même API, validée contre les vraies limites de chaque plateforme, avec des résultats simulés. Vous pouvez construire et tester l’interface maintenant, puis basculer quand ces réseaux passent en production.

À essayer

Créez une clé et planifiez votre premier post →

Testez tout pendant 15 jours pour 5 $. Growth : 25 comptes, 5 000 publications par mois et les webhooks, pour 49 $/mois. Voir les tarifs.