Vos utilisateurs créent quelque chose dans votre produit puis le quittent pour le publier ailleurs. Combler cet écart est une demande de fonctionnalité courante, et la forme du travail dépend presque entièrement d’une décision prise au départ.
La décision : à qui appartient le compte ?
Si les publications vont sur vos propres comptes, une clé API suffit. Serveur à serveur, aucun flux de consentement, la chose la plus simple possible.
Si les publications vont sur les comptes de vos utilisateurs, il vous faut OAuth. Chaque utilisateur autorise votre application et vous recevez un jeton restreint lié à l’espace de travail qu’il a choisi.
Faites bien cela dès le départ. Les produits qui commencent en demandant aux utilisateurs de coller une clé API finissent par migrer vers OAuth plus tard, et entre-temps ils ont appris aux utilisateurs une habitude mauvaise pour les deux parties : coller un identifiant à longue durée de vie et à large accès dans un produit tiers.
Ce que vous devriez construire autrement
La raison d’utiliser une API de publication plutôt que d’intégrer les plateformes directement, c’est que l’intégration directe est un projet par plateforme qui ne se termine jamais :
- Un flux OAuth distinct par plateforme, avec des scopes et des durées de vie de jeton différents
- Une tâche de rafraîchissement par plateforme, qui échoue silencieusement et emporte la publication avec elle
- Un pipeline de médias distinct par plateforme, avec des modèles d’upload différents
- Une publication asynchrone sur plusieurs d’entre elles, où un 200 ne signifie pas publié
- Une limite de débit distincte par plateforme
- Une revue d’application sur plusieurs, ce qui est du temps calendaire que vous ne contrôlez pas et qui peut être refusé
- Des changements cassants continus, selon le calendrier propre à chaque plateforme
Pour un SaaS où la publication est une fonctionnalité plutôt que le produit, c’est un engagement de maintenance permanent attaché à quelque chose qui n’est pas votre différenciateur.
Ce que vous construisez quand même
Utiliser une API de publication ne supprime pas tout le travail. Vous avez encore besoin de :
Une interface de connexion. Un endroit où les utilisateurs connectent leurs comptes et voient l’état de la connexion.
Un état de rupture visible. Les connexions se cassent. Les utilisateurs doivent le voir et le corriger, et cela doit être un état de votre produit plutôt qu’une erreur que vous avalez.
La composition, selon les termes de votre produit. L’API prend du contenu et des canaux. Ce que vos utilisateurs font réellement, et comment cela se traduit en publication, vous appartient.
La gestion des échecs. Quelque chose échouera à se publier. Décidez dès maintenant si l’utilisateur l’apprend de vous ou de l’absence d’une publication.
Ce qu’il faut vérifier avant de choisir
| Exigence | Pourquoi |
|---|---|
| OAuth avec scopes granulaires | Les produits multi-utilisateurs en ont besoin, et des scopes étroits limitent le rayon d’impact |
| La liste précise des plateformes | Pas « tous les grands réseaux » |
| Validation à la création | Pour qu’une légende trop longue échoue là où vous pouvez le montrer à l’utilisateur |
| Limites de débit à votre palier | Le chiffre qui décide si cela s’adapte avec vous |
| Erreurs structurées | Pour pouvoir afficher quelque chose d’utile plutôt que « la publication a échoué » |
BulkPublish pour cela
- Authentification : OAuth 2.1 pour agir sur les comptes de vos utilisateurs, clés API pour les vôtres
- Détails OAuth : PKCE (S256) obligatoire,
scopeobligatoire sans défaut implicite, codes d’autorisation à usage unique, jetons de rafraîchissement rotatifs, jetons transmis commeBearer bpat_... - Scopes :
posts:read,posts:write,media:read,media:write,analytics:read,channels:read,full - Surface : 59 points de terminaison documentés
- Plateformes : 15
Une limite autour de laquelle concevoir : les jetons OAuth atteignent les publications, les plannings, les labels, les médias, l’analytique, l’utilisation du quota et les données de canaux en lecture seule. L’administration du compte, c’est-à-dire l’équipe, les organisations, la facturation, les achats de crédits, les clés API et la gestion des applications OAuth, renvoie 403 pour tout jeton OAuth y compris full, parce que ces actions survivraient à la déconnexion de votre application par un utilisateur. Cela nécessite une clé API.
Mieux vaut le savoir maintenant que de le découvrir comme un 403 inexpliqué en production.
| Free | Pro | Business | |
|---|---|---|---|
| Requêtes API/jour | 30 | 5 000 | 50 000 |
| Clés API | 1 | 5 | 10 |
En résumé
Décidez d’abord si vous publiez sur vos propres comptes ou sur ceux de vos utilisateurs. Si c’est ceux des utilisateurs, utilisez OAuth dès le premier jour plutôt que de migrer plus tard. Intégrer les plateformes directement est un engagement de maintenance permanent sur quelque chose qui n’est pas votre produit, et les parties que vous devez encore construire sont l’interface de connexion, un état de rupture visible, et l’information des utilisateurs en cas d’échec.