Je product moet posten naar sociale platforms. Iemand zal vragen of je de platforms direct integreert of een publicatie-API gebruikt, en het eerlijke antwoord hangt af van dingen die niet in de eerste schatting voorkomen.
De schatting die altijd fout is
De eerste schatting is voor het gelukkige pad op één platform: een token krijgen, wat tekst posten, klaar. Dat deel is oprecht een paar dagen werk.
Dit is wat de schatting weglaat, per platform.
Tokenlevenscyclus. Tokens verlopen. Sommige in weken. Ze verversen is een geplande taak, en wanneer die faalt, is het falen stil: de verbinding is dood, publiceren mislukt, en niemand ontdekt het tot een gebruiker klaagt. Je hebt detectie en een herverbindingsflow nodig.
Media. Elk platform verwerkt media anders. Sommige halen een URL op. Sommige willen een hervatbare gefragmenteerde upload. Sommige willen specifieke afmetingen, duren of codecs, en weigeren al het andere. Je gaat hosten en mogelijk transcoderen.
Asynchrone publicatie. Bij verschillende platforms betekent je post accepteren niet dat hij is gepubliceerd. Je krijgt een id en pollt op status, en de uiteindelijke mislukking komt lang nadat je verzoek 200 teruggaf. Je datamodel heeft een “we denken dat dit publiceert”-status nodig, wat niet vanzelfsprekend is tot je het tegenkomt.
Rate limits. Andere vensters, andere headers, ander gedrag bij overschrijding. Je hebt wachtrijen en backoff nodig per platform.
Goedkeuring. Verschillende platforms hekken publiceren achter een reviewproces, met eisen over je app, je privacybeleid en soms een demovideo. Dit is kalendertijd die je niet kunt inkorten, en het kan worden geweigerd.
Doorlopende verandering. API-versies worden afgeschaft op het schema van het platform. Velden worden hernoemd. Rechten worden aangescherpt. Elk is ongepland werk met een deadline die jij niet hebt gesteld.
Dat laatste punt is degene die dit bepaalt. Bouwen is geen project dat af raakt, het is een permanente onderhoudsverplichting die groeit met elk platform.
De echte vergelijking
Niet “een paar dagen per platform” tegenover een abonnement. Het is:
| Bouwen | Kopen | |
|---|---|---|
| Initieel | Weken per platform, plus goedkeuringstijd die je niet in de hand hebt | Eén integratie |
| Doorlopend | Platformwijzigingen, mislukte tokenverversingen, mediapijplijn | Opgevangen door de provider |
| Platform toevoegen | Nog een volledige integratie | Een parameter |
| Faalmodi | Aan jou om te detecteren, debuggen en uit te leggen | Blootgelegd door de provider |
| Goedkeuring | Aan jou om te verkrijgen en te onderhouden per platform | Al in handen |
Wanneer bouwen juist is
Drie gevallen waarin dat echt zo is.
Eén platform, permanent. Als je naar precies één netwerk publiceert en dat niet gaat veranderen, is een directe integratie simpeler en verwijdert het een afhankelijkheid.
Publiceren is je product. Als je onderscheidende factor de publicatielaag is, is dat het ding dat je zou moeten bezitten.
Je hebt diepgang nodig voorbij publiceren. Advertentiebeheer, volledige commentaarmoderatie, diepgaande analytics. Deze gaan verder dan wat een publicatie-API dekt, en je zit toch al op de eigen API van het platform.
Wanneer kopen juist is
Alles dat drie of meer platforms bereikt waar publiceren een functie is in plaats van het product. Het onderhoud is de kost, niet de bouw, en het onderhoud schaalt met platformaantal terwijl je team dat niet doet.
Ook: alles met een deadline. Platformgoedkeuringsprocessen duren zo lang als ze duren, en kopen betekent dat iemand ze al heeft doorlopen.
Wat je controleert voordat je koopt
- De ondersteunde platformlijst, specifiek. Niet “alle grote netwerken”
- Auth-model. Als je gebruikers hun eigen accounts verbinden, heb je OAuth nodig, niet alleen een API-key
- Rate limits bij de laag waar je daadwerkelijk op zou zitten
- Webhooks, zodat je zonder pollen over mislukkingen hoort
- Of validatie gebeurt voor publicatie. Een bijschrift over de limiet pas bij publicatie ontdekken betekent een mislukte post
- Wat er gebeurt als een platform breekt. Dit is waar je voor betaalt
De BulkPublish API
- Basis-URL:
https://app.bulkpublish.com - Auth: API-key voor je eigen account, OAuth 2.1 voor handelen namens andermans
- Oppervlak: 59 gedocumenteerde endpoints voor posts, planning, media, kanalen, labels, analytics, RSS-feeds en quota
- Platforms: 15
| Free | Pro | Business | |
|---|---|---|---|
| API-verzoeken/dag | 30 | 5.000 | 50.000 |
| API-keys | 1 | 5 | 10 |
| Node- en Python-SDK’s, een Postman-collectie, en een MCP-server voor AI-agents. De gratis laag is gemaakt om de API te evalueren, niet om productieverkeer op te draaien. |
De korte versie
De bouwschatting klopt meestal voor het eerste platform en niet voor alles daarna, want de kost is onderhoud in plaats van constructie. Bouw als je voor altijd op één platform zit, als publiceren je product is, of als je diepgang nodig hebt voorbij publiceren. Anders is de integratie die je niet onderhoudt meer waard dan degene die je wel onderhoudt.