Scheduling by hand works until volume arrives. One week of posts across four networks is a dozen entries typed into a form, each with its own time, caption, and image. The moment a spreadsheet, a CMS, or another service already knows what needs to go out, retyping it into a calendar is the slowest possible way to publish.
A scheduling API inverts that. Your code owns the schedule, the API owns the platform connections, and the posts land on a calendar you can still review. This guide uses SocialRobot's REST API because the OAuth part is already solved: you link accounts once in the app and never register a Meta or LinkedIn developer app yourself.
What the API actually does
The API is the same engine the dashboard uses, exposed over HTTP. One request can target several networks, use the text you want per network, attach uploaded media, and then be listed, moved, or deleted later from the same endpoints.
Three things make it different from writing platform integrations by hand:
- One auth for nine networks. A single API key replaces per-platform OAuth apps, token refreshes, and the review process some networks require.
- Posts land in a reviewable queue. API posts are scheduled items on the calendar, not fire-and-forget calls. You approve in the dashboard, or the timer approves for you.
- The spec is public. OpenAPI 3 at
https://socialrobot.io/api/openapi.json, so Postman, Insomnia, or a generated client can import it in seconds.
Before the first request
You need three things:
- Connected accounts. Link Instagram, LinkedIn, X, and the rest under Scheduler, then Accounts. The API publishes through those logins.
- An API key. In the dashboard, Scheduler settings, then API keys. Copy the key once, it is sent as
x-api-key(Authorization: Beareralso works). - Account IDs. Call
GET /accountsto see what the key can publish to.
curl https://socialrobot.io/api/accounts \
-H "x-api-key: $SOCIALROBOT_API_KEY"
The response lists every connected account with its platform and its ID. Those IDs are what you put in targets later, so it is worth caching them per environment.
Create a scheduled post
One endpoint handles the common case: POST /posts. Text, time, targets.
curl -X POST https://socialrobot.io/api/posts \
-H "x-api-key: $SOCIALROBOT_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"content": "New oat flat coffee is live this week.",
"scheduledAt": "2026-09-15T09:00:00Z",
"targets": [
{ "platform": "instagram", "accountId": "acc_123" },
{ "platform": "linkedin", "accountId": "acc_456" },
{ "platform": "x", "accountId": "acc_789" }
]
}'
targets is the part that saves the most work: one request, three networks, one schedule. If a network needs different wording, create separate posts or use the per-platform endpoints below.
Scheduling is the default, not an extra step
A future scheduledAt puts the post on the calendar where you can still edit or delete it. Publishing on request is the same call with the timestamp omitted.
Attach media
Two ways in, depending on who holds the file:
Both return a media reference you pass in the post body, so you can queue a post and its image in one flow.
Move, list, and delete
The post ID from the create response is enough to manage everything afterward:
That covers the ugly part of automation. A campaign that slips a day is one request, not a support ticket.
When the generic endpoint is not enough
Some networks need a field the shared endpoint does not model. Those have their own routes: /instagram/create, /linkedin/create, /x/create, /tiktok/create, /pinterest/create, /threads/create, /facebook/create, /bluesky/create, and /mastodon/create.
Pinterest is the clearest example. A pin cannot exist without a board, so you list boards with GET /pinterest/boards/{accountId}, create one with POST /pinterest/create if needed, and then queue the pin. TikTok is similar: GET /tiktok/creator-info/{accountId} returns the posting options, including whether the video publishes directly or lands as an inbox draft.
API, MCP, or n8n?
All three drive the same publishing engine. Pick by who is holding the decision:
Quota is shared across the three, so mixing is normal: schedule from code during the week, adjust by chat when the plan changes.
Mistakes worth avoiding
- Hardcoding account IDs. They change when someone reconnects an account. Read them from
GET /accountsat startup. - Sending local times instead of UTC.
scheduledAtis an ISO 8601 timestamp. Store UTC, convert for display only. - Ignoring the response body. The create call returns the post ID and per-target status, which is what you need to log, retry, or reconcile.
- Publishing straight to the platform from a script. You lose the review step and the calendar. Keep the posts in SocialRobot and let the API do both.
Getting started
- Create a free SocialRobot account.
- Link the accounts you publish to.
- Create an API key in Scheduler settings.
- Run
GET /accounts, then queue your first post withPOST /posts. - Keep the OpenAPI spec open for the exact fields, and read the MCP walkthrough if an AI assistant should be the one scheduling.
Connect your accounts. Approve every post.
SocialRobot MCP is free on every plan. Add socialrobot.io/api/mcp to Claude, ChatGPT, or Cursor and schedule from chat. Nothing goes live until you approve it.
Read the MCP guide