An agent publishing to social media has different requirements from a person doing it, and most of them come from the same fact: nobody is watching at the moment it acts.
This page is a checklist for judging a publishing API for agent use, with the failure modes behind each item. If you want the practical walkthrough of connecting an agent and setting it up safely, see how to let an AI agent post to social media. The product page for the API itself is social media API for AI agents.
What an agent needs that a person doesn’t
A draft state that is genuinely useful. Not a hidden queue, but posts a human can see, review and publish. This is the most important feature for agent publishing and the one most often treated as an afterthought.
Validation when the post is created. A person notices a caption is too long. An agent doesn’t, and if the check happens at publish time, the failure lands hours later when the agent is gone. Errors have to come back on the create call, where the agent can react.
Scoped, revocable credentials. Separate from your other keys. When something goes wrong you want to revoke exactly the agent, not rotate the credential your production pipeline shares.
Quotas that stop a loop. A retry loop can produce a lot of posts fast. A hard ceiling is a safety feature here, not just a billing tier.
Structured errors. An agent can act on “caption exceeds 280 characters on x”. It can’t act on a generic 400.
The failure modes to design against
Confident invention. A model will produce a plausible statistic, price or feature claim rather than saying it does not know. Nothing factual should be generated. Facts come from a source your code controls.
Retry storms. An agent that treats a timeout as failure and retries can duplicate posts, because a timed-out create may have succeeded. Retries need to be safe or checked, never blind.
Publishing at the wrong moment. An agent has no idea that today is a bad day to post something cheerful. Anything touching news or controversy needs a human.
Voice drift. Left alone, generated posts converge on the same register, and an audience notices before you do.
Questions to put to any publishing API
| Question | What a good answer looks like |
|---|---|
| Can a post be saved without publishing? | Yes, as a draft, through the same endpoint |
| When are limits checked? | On create, with the platform named in the error |
| Can a key be limited? | By scope, and revoked on its own |
| What happens on a timeout? | You can look the post up before you retry |
| What stops a loop? | A daily request cap and a daily post cap |
What BulkPublish provides
- Connection: an MCP server for assistants, API keys for your own code, OAuth 2.1 for acting on other people’s accounts
- API: a documented REST API covering posts, scheduling, media, channels, labels, analytics, RSS feeds and quotas
- Validation: character limits and per-platform media rules checked when the post is created, not at publish
- Platforms: 15
| Free | Pro | Business | |
|---|---|---|---|
| API requests/day | 10 | 5,000 | 50,000 |
| API keys | 1 | 5 | 10 |
| Posts | 1/day | 30/day | Unlimited |
OAuth scopes are granular (posts:read, posts:write, media:read, media:write, analytics:read, channels:read, inbox:read, inbox:write and full), so an agent that only needs to create posts does not get the inbox.
The short version
An agent needs a real draft state, validation on create, scoped credentials it can lose without taking anything else down, and quotas that stop a loop. Never let it generate a fact, and keep a human between generation and publication until you have a strong reason not to.
