Als je programmatisch publiceert, gelden er twee aparte rate limits, en slechts één ervan heb je in eigen hand.
De twee niveaus
De limiet van het platform. Elk sociaal netwerk beperkt hoeveel elke applicatie kan doen op zijn API, met een eigen venster, eigen headers en eigen gedrag bij overschrijding. Deze verschillen per platform en veranderen zonder veel aankondiging.
De limiet van je provider. Als je publiceert via een unified API, heeft die dienst ook een limiet, meestal gekoppeld aan je abonnement.
De tweede is gemakkelijk te lezen en tegen te plannen. De eerste is degene die pijn doet, omdat je hem nooit rechtstreeks ziet als je een unified API gebruikt. De provider absorbeert hem, wat een groot deel is van waarvoor je betaalt, maar hij verdwijnt niet: een platform dat iedereen throttelt, betekent nog steeds dat jouw post vertraagd wordt.
Ontwerp voor vertraging, niet alleen voor fouten
De meest voorkomende fout in een publicatiepijplijn is “geaccepteerd” behandelen als “gepubliceerd”.
Bij verschillende platforms geeft het indienen van een post succes terug en gebeurt de daadwerkelijke publicatie daarna. Dus de mislukking komt later aan, buiten de band, lang nadat je verzoek 200 teruggaf. Als je datamodel alleen “verzonden” en “mislukt” heeft, is er nergens om “we denken dat dit aan het publiceren is” te plaatsen.
Ontwerp voor drie statussen, en maak de wachtende zichtbaar.
Praktische regels
Wacht exponentieel. Bij een 429, wacht en probeer opnieuw met een toenemende vertraging. Onmiddellijke pogingen maken de situatie erger en kunnen een throttle verlengen.
Begrens je pogingen. Een pijplijn die eindeloos opnieuw probeert, is hoe een quota in minuten verdwijnt. Geef op, log luid, en laat een mens kijken.
Probeer een create nooit blindelings opnieuw. Als een create-verzoek time-out geeft, weet je niet of het is gelukt. Opnieuw proberen kan dubbele posts opleveren, wat erger is dan de oorspronkelijke mislukking. Controleer voordat je opnieuw probeert, of gebruik een aanpak die de herhaling veilig maakt.
Batch waar een endpoint het ondersteunt. Eén verzoek dat veel posts aanmaakt, kost één verzoek. Hetzelfde werk als vijftig losse aanroepen kost vijftig.
De eigen limieten van BulkPublish
| Free | Pro | Business | |
|---|---|---|---|
| API-verzoeken/dag | 30 | 5.000 | 50.000 |
| API-sleutels | 1 | 5 | 10 |
| Posts | 3/dag | 30/dag | Onbeperkt |
De 30 verzoeken per dag van het gratis abonnement zijn bewust gedimensioneerd om de API te evalueren en iets lichts en persoonlijks te draaien. Het is niet genoeg om een echte pijplijn te draaien, en een lus zonder backoff put het in seconden uit.
Let op dat API-verzoeken en posts aparte limieten zijn. Kanalen opsommen, status controleren en media uploaden verbruiken allemaal verzoeken zonder een post aan te maken, dus het verzoekbudget reikt verder dan het aantal posts suggereert, maar alleen als je het zorgvuldig gebruikt.
Meerdere sleutels zijn voor scheiding, niet meer capaciteit
Betaalde abonnementen bevatten verschillende API-sleutels, en de reden is niet extra doorvoer. Het is zodat verschillende dingen verschillende credentials kunnen hebben: je productiepijplijn, een staging-omgeving, een AI-agent.
De waarde blijkt wanneer er iets misgaat. Je trekt om 2 uur ‘s nachts één sleutel in in plaats van de ene credential te roteren die alles deelt.
Een verstandige vorm voor een publicatietaak
- Zoek kanalen één keer op bij het opstarten, niet per post
- Upload media, maak dan posts aan die naar de id’s verwijzen
- Gebruik batch-endpoints waar ze bestaan
- Handel 429 af met exponentiële backoff en een limiet op pogingen
- Log elke mislukking met de responsbody, want niemand kijkt toe
De korte versie
Twee limieten gelden: die van het platform, die je niet ziet via een unified API, en die van je provider, die je wel ziet. Wacht exponentieel, begrens pogingen, probeer een create nooit blindelings opnieuw, batch waar je kunt. En behandel “geaccepteerd” als een status apart van “gepubliceerd”, want bij verschillende platforms is dat oprecht zo.