Your product needs to post to social platforms. Someone will ask whether to integrate the platforms directly or use a publishing API, and the honest answer depends on things that don’t show up in the first estimate.
The estimate that’s always wrong
The first estimate is for the happy path on one platform: get a token, post some text, done. That part is genuinely a couple of days.
Here’s what the estimate leaves out, per platform.
Token lifecycle. Tokens expire. Some in weeks. Refreshing them is a scheduled job, and when it fails the failure is silent: the connection is dead, publishing fails, and nobody finds out until a user complains. You need detection and a reconnection flow.
Media. Every platform ingests media differently. Some fetch a URL. Some want a resumable chunked upload. Some want specific dimensions, durations or codecs, and reject anything else. You’ll be hosting and possibly transcoding.
Asynchronous publishing. On several platforms, accepting your post is not publishing it. You get an id and poll for status, and the eventual failure arrives long after your request returned 200. Your data model needs a “we think this is publishing” state, which is not obvious until you hit it.
Rate limits. Different windows, different headers, different behaviour when exceeded. You need queuing and backoff per platform.
Approval. Several platforms gate publishing behind a review process, with requirements about your app, your privacy policy and sometimes a demo video. This is calendar time you can’t compress, and it can be refused.
Ongoing change. API versions get deprecated on the platform’s schedule. Fields get renamed. Permissions get tightened. Each one is unplanned work with a deadline you didn’t set.
That last item is the one that decides this. Building isn’t a project that finishes, it’s a permanent maintenance commitment that grows with each platform.
The real comparison
Not “a few days per platform” against a subscription. It’s:
| Build | Buy | |
|---|---|---|
| Initial | Weeks per platform, plus approval time you don’t control | One integration |
| Ongoing | Platform changes, token refresh failures, media pipeline | Absorbed by the provider |
| Adding a platform | Another full integration | A parameter |
| Failure modes | Yours to detect, debug and explain | Surfaced by the provider |
| Approval | Yours to obtain and maintain per platform | Already held |
When building is right
Three cases where it genuinely is.
One platform, permanently. If you publish to exactly one network and that won’t change, a direct integration is simpler and removes a dependency.
Publishing is your product. If your differentiator is the publishing layer, that’s the thing you should own.
You need depth beyond publishing. Ad management, full comment moderation, deep analytics. These go past what a publishing API covers, and you’ll be on the platform’s own API anyway.
When buying is right
Anything reaching three or more platforms where publishing is a feature rather than the product. The maintenance is the cost, not the build, and the maintenance scales with platform count while your team doesn’t.
Also: anything on a deadline. Platform approval processes take as long as they take, and buying means someone already went through them.
What to check before buying
- The supported platform list, specifically. Not “all major networks”
- Auth model. If your users connect their own accounts, you need OAuth, not just an API key
- Rate limits at the tier you’d actually be on
- Webhooks, so you learn about failures without polling
- Whether validation happens before publishing. Catching an over-limit caption at publish time means a failed post
- What happens when a platform breaks. This is the thing you’re paying for
The BulkPublish API
- Base URL:
https://app.bulkpublish.com - Auth: API key for your own account, OAuth 2.1 for acting on behalf of other people’s
- Surface: 59 documented endpoints covering posts, scheduling, media, channels, labels, analytics, RSS feeds and quotas
- Platforms: 15
| Free | Pro | Business | |
|---|---|---|---|
| API requests/day | 30 | 5,000 | 50,000 |
| API keys | 1 | 5 | 10 |
| Node and Python SDKs, a Postman collection, and an MCP server for AI agents. The free tier is sized for evaluating the API rather than running production traffic. |
The short version
The build estimate is usually right about the first platform and wrong about everything after it, because the cost is maintenance rather than construction. Build if you’re on one platform forever, if publishing is your product, or if you need depth past publishing. Otherwise the integration you don’t maintain is worth more than the one you do.