Meteen publiceren via een API is eenvoudig. Inplannen is waar de interessante problemen zitten, want een ingeplande post is een belofte over de toekomst, en de toekomst bevat zomertijd, storingen en posts waarvan je van gedachten verandert.
Tijdzones: geef er expliciet één mee
De meest voorkomende planningsbug is een post die twee keer per jaar een uur verschuift.
Een ingeplande tijd heeft twee dingen nodig: het moment, als een ISO-8601-tijdstempel, en de zone waarin het is uitgedrukt, als een IANA-naam zoals America/New_York.
await bp.posts.create({
content: 'Morning update.',
channels: [{ channelId: 1, platform: 'linkedin' }],
status: 'scheduled',
scheduledAt: '2026-04-10T14:00:00Z',
timezone: 'America/New_York',
});Alleen een UTC-moment opslaan is prima voor een eenmalige actie. Het is fout voor alles wat terugkerend is, want “elke werkdag om 9 uur lokale tijd” is een ander UTC-moment vóór en na een zomertijdwijziging. De zone is wat dat correct maakt.
Sla nooit een ruwe offset zoals -05:00 op als vervanging voor een zone. Offsets veranderen, zones niet.
Modelleer meer dan twee statussen
Een post is niet alleen ingepland of gepubliceerd. Bouw voor ten minste:
- draft, aangemaakt maar niet ingepland
- scheduled, ingepland voor een tijdstip
- processing, verzonden naar het platform, uitkomst onbekend
- published, bevestigd live
- failed, met een reden
- partial, gepubliceerd naar sommige doelen en niet naar andere
De twee die mensen vergeten zijn processing en partial.
processing bestaat omdat verschillende platforms een post accepteren en asynchroon publiceren. Een 200 is geen publicatie, en de echte uitkomst komt later binnen.
partial bestaat omdat één post meestal meerdere platforms als doel heeft. Als drie slagen en één mislukt, is noch “published” noch “failed” waar, en het in een van beide forceren levert een UI op die tegen de gebruiker liegt.
Wat er gebeurt als een platform down is
Ontwerp ervoor, want het gebeurt.
Tijdelijke fouten moeten opnieuw geprobeerd worden met backoff. Een platform dat twee minuten lang 503 teruggeeft, zou de post niet moeten verliezen.
Retries moeten veilig zijn. Een create die time-out gaf, kan toch gelukt zijn. Blindelings opnieuw proberen dupliceert de post, wat erger is dan de oorspronkelijke fout. Controleer voordat je opnieuw probeert.
Permanente fouten zouden helemaal niet opnieuw geprobeerd moeten worden. Een verlopen token of een ongeldige caption lost zichzelf niet op, en opnieuw proberen verbrandt alleen quota en vertraagt de melding.
Iemand moet het weten. Een mislukte ingeplande post om 3 uur ‘s nachts is stil tenzij je hem luidruchtig hebt gemaakt. Webhooks zijn het juiste mechanisme.
Bewerken en annuleren
Een ingeplande post is een belofte die je mogelijk moet breken. Je integratie zou het wijzigen van de tijd, het bewerken van content en het volledig annuleren moeten ondersteunen.
Let op dat platforms verschillen in of ze dit toestaan zodra zij de post vasthouden, wat een van de redenen is waarom inplannen in je eigen laag en op het laatste moment indienen beter werkt dan het platform een toekomstig gedateerde post geven.
Wachtrijslots versus expliciete tijden
Twee planningsmodellen, en beide hebben hun plaats.
Expliciete tijden zijn wat je wilt wanneer een post op een bepaald moment moet landen: een lancering, een evenement, een gecoördineerde aankondiging.
Wachtrijslots zijn wat je wilt voor een gestage druppel. Je definieert een postingcadans en de volgende post neemt het volgende vrije slot, zodat je niet voor elke post in een batch tijdstempels hoeft te kiezen.
Voor bulkwerk is de tweede veel minder omslachtig, en het is het model dat van “dertig posts in de wachtrij zetten” een zinnige handeling maakt in plaats van dertig beslissingen.
Terugkerende schema’s
Anders dan een ingeplande post. Een terugkerend schema is een regel die posts blijft produceren op een frequentie: dagelijks, wekelijks, tweewekelijks of maandelijks.
Twee dingen om voor te ontwerpen. De zone doet er hier nog meer toe, om de zomertijdreden hierboven. En media die aan een terugkerende post is gekoppeld, moet bewaard blijven in plaats van opgeruimd na publicatie, want het schema heeft het de volgende keer weer nodig.
Abonnementslimieten
| Free | Pro | Business | |
|---|---|---|---|
| API-verzoeken/dag | 30 | 5.000 | 50.000 |
| Posts | 3/dag | 30/dag | Onbeperkt |
| Terugkerende schema’s | Geen | 10 | Onbeperkt |
De korte versie
Geef een IANA-tijdzone mee naast elk ingepland tijdstempel, vooral voor alles wat terugkerend is. Modelleer processing en partial als echte statussen, want asynchroon publiceren en posts naar meerdere platforms maken beide oprecht mogelijk. Probeer tijdelijke fouten opnieuw met backoff, probeer een create nooit blindelings opnieuw, en gebruik webhooks zodat een mislukking om 3 uur ‘s nachts niet stil blijft.