Het planningsgedeelte van een social media planner is een weekendklus. Een wachtrij, een worker, een cron. Dat is oprecht niet moeilijk, en dat is precies waarom de schatting altijd verkeerd is.
Alles wat duur is, zit aan de andere kant ervan.
Het deel dat makkelijk is
Een tabel met berichten met een geplande tijd, een worker die wakker wordt, verlopen berichten vindt en publiceert. Voeg een retry toe en je bent klaar.
Als je dit bouwt als leerproject of voor één platform dat je zelf beheert, stop dan met lezen. De rest hiervan gaat over wat er gebeurt zodra echte accounts en meerdere platforms erbij komen.
Het datamodel dat je echt nodig hebt
Meer statussen dan mensen verwachten:
- draft, aangemaakt maar niet ingepland
- scheduled, ingepland voor een tijdstip
- processing, verzonden naar het platform, uitkomst onbekend
- published, bevestigd
- failed, met een reden
- partial, gepubliceerd naar sommige doelen en niet naar andere
processing bestaat omdat verschillende platforms een bericht accepteren en asynchroon publiceren. Een 200 is geen publicatie, en de uitkomst komt later, buiten de directe respons om. Zonder deze status claimt je UI succes en heeft het soms ongelijk.
partial bestaat omdat één bericht meestal meerdere platforms als doel heeft. Drie slagen, één mislukt. Noch “published” noch “failed” is waar, en het in een van beide forceren levert een product op dat tegen zijn gebruikers liegt.
Je hebt ook rijen per doel nodig in plaats van één status op het bericht, omdat de mislukking per platform verschilt.
Tijdzones
Sla het moment en de IANA-zone op, niet een offset.
“Elke werkdag om 9 uur lokale tijd” is een ander UTC-moment voor en na een overgang naar zomer- of wintertijd. Alleen UTC opslaan werkt tot maart, waarna alles een uur verschuift en de bugmeldingen verwarrend zijn omdat het de helft van het jaar wel klopt.
Het platformwerk
Hier breekt de schatting. Per platform:
Een aparte OAuth-flow. Andere scopes, andere tokenlevensduur, andere toestemmingsschermen.
Een aparte refresh-job. Dit is degene die pijn doet. Tokens verlopen, refresh mislukt stilzwijgend, en niemand ontdekt het totdat een gepland bericht niet wordt gepubliceerd. Je hebt geplande refresh, monitoring voor refresh-mislukking, een status voor verbroken verbinding en een herverbindingsflow nodig. Dat is meer werk dan de OAuth-flow zelf.
Een aparte mediapijplijn. Het ene platform haalt een URL op, het andere wil een hervatbare, gesegmenteerde upload, weer een ander wil specifieke afmetingen of codecs. Je gaat hosten en mogelijk transcoderen.
Een aparte ratelimiet, met zijn eigen venster en eigen gedrag bij overschrijding.
App-review. Verschillende platforms sluiten publiceren af achter een review van je app, een privacybeleid en soms een demovideo. Dat is kalendertijd die je niet zelf beheert, en die kan worden afgewezen.
Voortdurende verandering. API-versies worden afgeschaft, velden hernoemd, rechten aangescherpt, op het schema van de platforms zelf. Elke keer is dat ongepland werk met een deadline die jij niet hebt bepaald.
Vermenigvuldig dat met het aantal platforms. En blijf het dan voor altijd betalen.
De publicatieregels
Naast levering is het enige wat gebruikers echt willen dat er niets wordt gepubliceerd dat zal worden afgewezen. Dat betekent per platform coderen:
- Tekenlimieten
- Media-aantallen, formaten, bestandsgroottes, duur, beeldverhoudingen
- Welke berichttypes media vereisen
- Welke formaten überhaupt bestaan
En valideren bij het aanmaken in plaats van bij het publiceren, want een mislukking op het moment van publiceren is er een waar de gebruiker pas achter komt nadat het moment voorbij is.
Bouw het als
- Je publiceert naar precies één platform, permanent
- Publiceren is je product en je onderscheidend vermogen
- Je hebt diepgang nodig ver voorbij publiceren, zoals advertentiebeheer
Bouw het niet als
Publiceren is een functie van iets anders dat je bouwt en het bereikt drie of meer platforms. De kosten zitten niet in het bouwen, maar in het onderhoud, en dat onderhoud schaalt met het aantal platforms terwijl je team dat niet doet.
Het alternatief
Eén integratie, waarbij de platformchurn het probleem van iemand anders is.
- Basis-URL:
https://app.bulkpublish.com - Auth: API-sleutel, of OAuth 2.1 als je namens de accounts van je gebruikers handelt
- Oppervlak: 59 gedocumenteerde endpoints
- Platforms: 15
- Validatie: limieten gecontroleerd bij aanmaken, niet bij publiceren
- SDK’s: Node en Python, plus een Postman-collectie en een MCP-server
| Free | Pro | Business | |
|---|---|---|---|
| API-verzoeken/dag | 30 | 5.000 | 50.000 |
| API-sleutels | 1 | 5 | 10 |
De korte versie
De wachtrij is een weekendklus. De statussen, de tijdzones, en één OAuth-flow plus één refresh-job plus één mediapijplijn per platform zijn het eigenlijke project, en de platformchurn zorgt ervoor dat het nooit af is. Bouw het als publiceren je product is of als je voor altijd op één platform blijft. Anders is de integratie die je niet onderhoudt meer waard dan degene die je wel onderhoudt.