Social Media CLI

Social media CLI for JSON-first publishing, agents, CI, and cron

bundlesocial-cli is a scriptable, agent-friendly command-line interface over the bundle.social API. JSON to stdout, status text to stderr, one command per workflow. Ships with a SKILL.md so agent runtimes auto-discover it.

Last updated: May 2026

API key authScheduled publishing14 platforms
Quick start
API request
1$ npx bundlesocial-cli posts:create \2    -c "We just shipped dark mode 🌙" \3    -i x -i bluesky -i mastodon45{6  "id": "post_3sf9k2",7  "status": "SCHEDULED",8  "socialAccountTypes": ["TWITTER", "BLUESKY", "MASTODON"],9  "data": {10    "TWITTER":  { "text": "We just shipped dark mode 🌙" },11    "BLUESKY":  { "text": "We just shipped dark mode 🌙" },12    "MASTODON": { "text": "We just shipped dark mode 🌙" }13  }14}1516# JSON on stdout, status text on stderr - easy for an agent to parse.17# Ships with a SKILL.md for agent-skill runtimes:18# $ npx skills add bundleglobal/bundlesocial-cli

Glueing curl + jq to every social platform

Shell scripts that call native platform APIs end up reimplementing OAuth refresh, multipart uploads and per-platform payload shapes.
Each platform has different error shapes - agents that shell out have to learn a dialect per integration.
Cron jobs and CI runners need machine-parseable output, not pretty tables - most CLIs don't separate stdout/stderr cleanly.

What bundle.social handles

JSON to stdout, status/log text to stderr - clean separation so agents and CI can pipe-and-parse.
One CLI for 14+ platforms - posts:create, posts:list, accounts:list, analytics:get - same shape per platform.
Ships with a SKILL.md (npx skills add bundleglobal/bundlesocial-cli) so agent-skill runtimes auto-discover and document it.

A CLI that's actually agent-friendly

Designed for shell-out agents, CI runners and cron - JSON by default, per-command exit codes, structured errors, no interactive prompts. The same CLI a human can use to ship a one-off post.

Workflow

How it works

Connect accounts once, then create and schedule posts with channel-specific fields from one API.

01

Install with npx

npx bundlesocial-cli@latest - or pin a version in package.json / a CI image.

02

Authenticate with an API key

Set BUNDLESOCIAL_API_KEY or pass --api-key. Org-scoped - no per-platform OAuth on the agent side.

03

Run commands or wire into CI

posts:create / posts:schedule / analytics:get - JSON in, JSON out. Drop into GitHub Actions, cron, or an agent's shell-out path.

Product architecture

Build social media workflows without rebuilding every platform

Social media CLI for scripts that need real publishing primitives

A social media CLI is most useful when it behaves like infrastructure, not a pretty dashboard squeezed into a terminal. Agents, CI jobs, release scripts, and cron workflows need deterministic commands, JSON output, clear exit codes, and errors that can be parsed without scraping human-oriented text. They also need the same account and post model your backend uses, otherwise every script becomes a separate integration surface.

bundlesocial-cli is built around that automation path. It lets a shell-out agent create posts, upload media, list accounts, fetch analytics, and schedule content without learning the native API dialect for every platform. The command line becomes a thin operational surface over the same bundle.social API, which means teams can automate publishing without turning bash scripts into long-lived social platform connectors.

Why JSON-first output matters for agents and CI

Agent runtimes and CI runners do not want tables, prompts, hidden state, or interactive setup in the middle of a workflow. They want one command to produce one structured response that can be piped into jq, stored in a job log, passed to another tool, or summarized by an LLM. Separating JSON on stdout from status text on stderr keeps automation predictable.

That pattern is especially important for social workflows because a successful request is not always the end of the story. A post can be scheduled, processing, failed, retried, or posted later. By returning IDs and structured state, the CLI lets the rest of your system inspect what happened after the command finishes, instead of treating publishing as a blind side effect.

One CLI over account connection, uploads, scheduling, and analytics

Direct native API scripting can work for one narrow platform, but it becomes painful when the workflow includes media uploads, multiple account types, scheduled content, platform validation, analytics lookups, and customer workspaces. Every platform adds a new credential model, payload shape, media rule, and failure format.

The bundle.social CLI keeps those workflows connected. A script can upload a file, receive an upload ID, create a post for X and LinkedIn, schedule it for later, then fetch analytics after publishing. Human operators can run the same commands during debugging, while agents and CI use them non-interactively. That shared surface makes the CLI practical for production automation rather than just one-off terminal demos.

Capabilities

CLI surface designed for automation

Every command returns structured JSON, supports --help, and behaves predictably in non-interactive shells.

posts:create / posts:schedule

Multi-platform posts in one invocation. -i x -i bluesky -i mastodon to fan out; --platform-settings to pass per-platform options.

media:upload

Upload a local file or URL, get an upload ID back. Reference the ID from posts:create - no base64, no chunking ceremony.

accounts:list / teams:list

Discover what an agent can post to before it tries. Filter by platform, team or account status.

analytics:get

Pull per-post and per-account analytics as JSON. Pipe into jq, into a dashboard, into an LLM as context.

Developer example

Schedule a multi-platform post from the shell

Examples use bundle.social's public API shape: API key authentication, a post date, selected social account types, and platform-specific data.

TypeScript
API request
1$ npx bundlesocial-cli posts:create \2    -c "We just shipped dark mode 🌙" \3    -i x -i bluesky -i mastodon45{6  "id": "post_3sf9k2",7  "status": "SCHEDULED",8  "socialAccountTypes": ["TWITTER", "BLUESKY", "MASTODON"],9  "data": {10    "TWITTER":  { "text": "We just shipped dark mode 🌙" },11    "BLUESKY":  { "text": "We just shipped dark mode 🌙" },12    "MASTODON": { "text": "We just shipped dark mode 🌙" }13  }14}1516# JSON on stdout, status text on stderr - easy for an agent to parse.17# Ships with a SKILL.md for agent-skill runtimes:18# $ npx skills add bundleglobal/bundlesocial-cli

Supported content

posts:createposts:schedulemedia:uploadaccounts:listanalytics:get

Honest limitations

  • Node 20+ required. (Use npx if you don't want a global install.)
  • Interactive prompts are off by default - meant for non-interactive shells. Enable with --interactive if you want them.
  • Same per-platform rules apply (TikTok privacy enum, YouTube category, X media constraints) - the CLI surfaces validation errors structured, not bypassed.

Guarantees

Developer-first infrastructure

2% error rate

We handle the platform edge cases, media processing, and rate limits so your requests succeed.

Verbose errors

When native APIs fail, we return human-readable error messages and actionable recovery steps.

Flat pricing

No per-post counting. Predictable pricing for teams managing many users, workspaces, and connected accounts.

Same-day support

Direct access to the engineers building the API. We respond to technical issues the same day. Sometimes the same hour. Test us c;

Resources

Technical guides & documentation

FAQ

Questions developers ask before building

Is this a wrapper over the SDK?

Yes. The CLI uses the bundlesocial TypeScript SDK underneath. Anything you can do from the CLI you can do from the SDK and the REST API directly.

How does the SKILL.md work?

Agent-skill runtimes look for SKILL.md inside published packages to auto-document tools they can shell out to. We ship one in bundlesocial-cli - npx skills add bundleglobal/bundlesocial-cli registers it with your skill runtime.

Does it work in CI?

Yes. It's the primary target. JSON-by-default output, non-interactive shells, exit codes per command, no global config needed - just BUNDLESOCIAL_API_KEY as a secret.

How is this different from the MCP server?

Use the CLI when an agent shells out (Claude Code subprocess, OpenCode, CI runners, cron). Use the MCP server when the client speaks the Model Context Protocol (Claude Desktop, Cursor). Same auth, same posts, different transport.