Se pubblichi in modo programmatico, si applicano due rate limit separati e solo uno di essi è sotto il tuo controllo.
I due livelli
Il limite della piattaforma. Ogni social network limita quanto un’applicazione può fare sulla sua API, con una propria finestra, propri header e proprio comportamento quando viene superato. Questi differiscono per piattaforma e cambiano senza molto preavviso.
Il limite del tuo provider. Se pubblichi tramite un’API unificata, anche quel servizio ha un limite, di solito legato al tuo piano.
Il secondo è facile da leggere e pianificare. Il primo è quello che morde, perché non lo vedi mai direttamente se usi un’API unificata. Il provider lo assorbe, il che è gran parte di ciò per cui stai pagando, ma non scompare: una piattaforma che limita tutti significa comunque che il tuo post viene ritardato.
Progetta per il ritardo, non solo per gli errori
L’errore più comune in una pipeline di pubblicazione è trattare “accettato” come “pubblicato”.
Su diverse piattaforme, inviare un post restituisce successo e la pubblicazione vera e propria avviene dopo. Quindi il fallimento arriva più tardi, fuori banda, molto dopo che la tua richiesta ha restituito 200. Se il tuo modello di dati ha solo “inviato” e “fallito”, non c’è dove mettere “pensiamo che questo si stia pubblicando”.
Progetta per tre stati, e rendi visibile quello in sospeso.
Regole pratiche
Rallenta in modo esponenziale. Su un 429, aspetta e riprova con un ritardo crescente. I retry immediati peggiorano la situazione e possono estendere una limitazione.
Limita i tuoi retry. Una pipeline che riprova all’infinito è il modo in cui una quota scompare in minuti. Rinuncia, registra rumorosamente, e lascia che un umano guardi.
Non riprovare mai una creazione alla cieca. Se una richiesta di creazione va in timeout, non sai se sia riuscita. Riprovare può produrre post duplicati, che è peggio del fallimento originale. Controlla prima di riprovare, o usa un approccio che rende il retry sicuro.
Raggruppa dove un endpoint lo supporta. Una richiesta che crea molti post costa una richiesta. Lo stesso lavoro come cinquanta chiamate individuali costa cinquanta.
I limiti di BulkPublish
| Free | Pro | Business | |
|---|---|---|---|
| Richieste API/giorno | 30 | 5.000 | 50.000 |
| API key | 1 | 5 | 10 |
| Post | 3/giorno | 30/giorno | Illimitati |
Le 30 richieste al giorno del piano gratuito sono dimensionate deliberatamente per valutare l’API e far girare qualcosa di leggero e personale. Non bastano per far girare una pipeline reale, e un ciclo senza backoff la esaurirà in pochi secondi.
Nota che le richieste API e i post sono limiti separati. Elencare i canali, controllare lo stato e caricare media consumano tutti richieste senza creare un post, quindi il budget di richieste va più lontano di quanto suggerisca il conteggio dei post solo se lo usi con attenzione.
Più chiavi servono per la separazione, non più capacità
I piani a pagamento includono diverse API key, e il motivo non è un throughput extra. È perché cose diverse possano avere credenziali diverse: la tua pipeline di produzione, un ambiente di staging, un agente AI.
Il valore emerge quando qualcosa va storto. Revochi una chiave alle 2 del mattino invece di ruotare l’unica credenziale che tutto condivide.
Una forma sensata per un job di pubblicazione
- Cerca i canali una volta all’avvio, non per ogni post
- Carica i media, poi crea i post facendo riferimento agli id
- Usa gli endpoint batch dove esistono
- Gestisci il 429 con backoff esponenziale e un tetto ai retry
- Registra ogni fallimento con il corpo della risposta, perché nessuno sta guardando
La versione breve
Si applicano due limiti: quello della piattaforma, che non puoi vedere attraverso un’API unificata, e quello del tuo provider, che puoi vedere. Rallenta in modo esponenziale, limita i retry, non riprovare mai una creazione alla cieca, raggruppa dove puoi. E tratta “accettato” come uno stato distinto da “pubblicato”, perché su diverse piattaforme lo è davvero.