I tuoi utenti creano qualcosa nel tuo prodotto e poi se ne vanno per pubblicarlo altrove. Colmare quel divario è una richiesta di funzionalità comune, e la forma del lavoro dipende quasi interamente da una decisione presa all’inizio.
La decisione: di chi è l’account?
Se i post vanno sui tuoi account, una API key basta. Server-to-server, nessun flusso di consenso, la cosa più semplice possibile.
Se i post vanno sugli account dei tuoi utenti, ti serve OAuth. Ogni utente autorizza la tua app e ricevi un token con ambito limitato legato allo spazio di lavoro che ha scelto.
Fai questa scelta bene fin dall’inizio. I prodotti che iniziano chiedendo agli utenti di incollare una API key finiscono per migrare a OAuth più tardi, e nel frattempo hanno insegnato agli utenti un’abitudine dannosa per entrambe le parti: incollare una credenziale a lunga durata con accesso ampio in un prodotto di terze parti.
Cosa dovresti costruire altrimenti
Il motivo per usare una API di pubblicazione invece di integrare direttamente le piattaforme è che l’integrazione diretta è un progetto per piattaforma che non finisce mai:
- Un flusso OAuth separato per piattaforma, con scope e durate dei token diversi
- Un job di refresh per piattaforma, che fallisce silenziosamente e si porta dietro la pubblicazione
- Una pipeline media separata per piattaforma, con modelli di upload diversi
- Pubblicazione asincrona su diverse, dove un 200 non significa pubblicato
- Un rate limit separato per piattaforma
- Revisione dell’app su diverse, che è tempo di calendario che non controlli e può essere rifiutato
- Cambiamenti che rompono la compatibilità in corso su ogni piattaforma secondo il proprio calendario
Per un SaaS dove la pubblicazione è una funzionalità piuttosto che il prodotto, quello è un impegno di manutenzione permanente legato a qualcosa che non è il tuo elemento distintivo.
Cosa costruisci comunque
Usare una API di pubblicazione non elimina tutto il lavoro. Devi comunque:
Un’interfaccia di connessione. Un posto dove gli utenti connettono i loro account e vedono lo stato della connessione.
Uno stato di rottura visibile. Le connessioni si rompono. Gli utenti devono vederlo e risolverlo, e deve essere uno stato nel tuo prodotto, non un errore che ingoi.
Composizione, nei termini del tuo prodotto. L’API accetta contenuto e canali. Cosa fanno effettivamente i tuoi utenti, e come si traduce in un post, è affar tuo.
Gestione dei fallimenti. Qualcosa fallirà a pubblicare. Decidi ora se l’utente lo scopre da te o dall’assenza di un post.
Cosa controllare quando scegli
| Requisito | Perché |
|---|---|
| OAuth con scope granulari | I prodotti multi-utente ne hanno bisogno, e scope ristretti limitano il raggio di danno |
| L’elenco specifico delle piattaforme | Non “tutte le principali reti” |
| Validazione alla creazione | Così una didascalia fuori limite fallisce dove puoi mostrarlo all’utente |
| Rate limit al tuo livello | Il numero che decide se scala con te |
| Errori strutturati | Così puoi mostrare qualcosa di utile invece di “pubblicazione fallita” |
BulkPublish per questo
- Autenticazione: OAuth 2.1 per agire sugli account dei tuoi utenti, API key per i tuoi
- Dettagli OAuth: PKCE (S256) obbligatorio,
scopeobbligatorio senza valore predefinito implicito, codici di autorizzazione monouso, refresh token rotanti, token passati comeBearer bpat_... - Scope:
posts:read,posts:write,media:read,media:write,analytics:read,channels:read,full - Superficie: 59 endpoint documentati
- Piattaforme: 15
Un confine da tenere presente nella progettazione: i token OAuth raggiungono post, programmazioni, etichette, media, analytics, uso della quota e dati dei canali in sola lettura. L’amministrazione dell’account, cioè team, organizzazioni, fatturazione, acquisti di crediti, API key e gestione delle app OAuth, restituisce 403 per qualsiasi token OAuth incluso full, perché quelle azioni sopravvivrebbero alla disconnessione della tua app da parte di un utente. Per quelle serve una API key.
Meglio saperlo ora che scoprirlo come un 403 inspiegabile in produzione.
| Free | Pro | Business | |
|---|---|---|---|
| Richieste API/giorno | 30 | 5.000 | 50.000 |
| API key | 1 | 5 | 10 |
La versione breve
Decidi prima se stai pubblicando sui tuoi account o su quelli dei tuoi utenti. Se sono degli utenti, usa OAuth fin dal primo giorno invece di migrare più tardi. Integrare direttamente le piattaforme è un impegno di manutenzione permanente su qualcosa che non è il tuo prodotto, e le parti che devi comunque costruire sono l’interfaccia di connessione, uno stato di rottura visibile, e avvisare gli utenti quando qualcosa è fallito.