Skip to main content

Live Posts

GET /posts answers a narrower question than the Social Champ calendar does, and the difference surprises people often enough to deserve its own page.

Two kinds of post​

Scheduled posts were created in Social Champ — through the app, the REST API, or the MCP tools — and published by us. These are what GET /posts returns by default.

Live posts were published straight to the network: from the Instagram app, from Meta Business Suite, from another scheduler. Social Champ never scheduled them; it discovered them afterwards while syncing analytics for the connected channel. They appear on the calendar's All view, they carry a working link to the network, and until you ask for them they are not in the API response.

So a channel can look empty over the API while the calendar shows a month of published content. Nothing has been lost — the two surfaces are answering different questions.

Including them​

curl -X GET "https://api.socialchamp.com/v1/rest/posts?livePosts=true&limit=25" \
  -H "Authorization: Bearer YOUR_TOKEN"

Live rows are marked, and their ids are namespaced:

{
  "id": "live_6a75a66fc29dd81ca141d247",
  "channelId": "69fb56dc24ca25c58dc0db73",
  "text": "Luxury Custom Design",
  "dateTime": "2026-08-06T21:05:00.000Z",
  "isPosted": true,
  "isLivePost": true,
  "permalinkUrl": "https://www.instagram.com/reel/Dbto3cSBYHn/",
  "type": null,
  "sourceType": null,
  "approvalStatus": null,
  "metrics": { "likes": 4 }
}

What to expect​

Ids beginning live_ are read only. There is no schedule behind them, so every write rejects them with an explanation rather than a not-found: PATCH /posts/{postId}, DELETE /posts/{postId}, /recycle, the label endpoints, and the bulk routes that take a postIds list.

Fields Social Champ never set are null, not missing. type, sourceType and approvalStatus are null on a live post. createdAt is not the exception it looks like: it is present, but it records when Social Champ first saw the post rather than when the post published, and it is null on rows recorded before we stored it. Use dateTime for publish time.

metrics runs the other way. It is sent on live posts only — null when the network has reported nothing yet, and absent altogether from a scheduled post.

The sort order changes. Without livePosts the page is ordered by creation time. With it, the two sources are merged on publish time, because a post we did not create has no creation time here. A cursor is therefore tied to the mode it was issued in — flip livePosts and start paging again, or the request is rejected with 400 Invalid cursor.

Media is mostly absent. videoUrls is always empty on a live post, and imageUrls is best-effort and usually empty too — the reel above has neither. Use permalinkUrl to reach the post on the network.

hasAssets and /posts/scheduled are incompatible with it. hasAssets=true filters on media we do not reliably have, and /posts/scheduled asks about posts that have not gone out yet, which no live post can be. Both combinations return 400 rather than a quietly wrong answer.

The hint in meta​

If you call GET /posts without stating a livePosts preference and the account has network-published content you are not being shown, the first page carries:

{
  "data": [],
  "paging": { "nextCursor": null, "hasMore": false },
  "meta": { "livePostsAvailable": true }
}

meta is advisory and is omitted when there is nothing to report. It is sent on the first page of GET /posts only, and never on a request that could not act on the advice — hasAssets=true and /posts/scheduled both reject livePosts, so neither is offered it.

Over MCP​

The MCP tool get_posts_for_channels reads the same data and had the same gap. It takes livePosts as a boolean:

Show me everything posted on my Instagram account in August, including posts published outside Social Champ.

The default answer covers scheduled posts only and says so, so an assistant that gets an empty result has something to act on.

With the flag set, this tool answers one question — what actually went out on these channels — so its scheduled half is limited to posts that have already published. Your upcoming queue is not mixed in; ask for scheduled posts separately. The other reading tools (get_scheduled_posts, get_posts_with_assets) are about posts that have not gone out yet or about media, and live posts are neither, so they reject the flag rather than ignore it.

Which one do you want?​

Reporting on what your team scheduled through Social Champ — approvals, queue health, what your automation published — is the default, and you should leave livePosts off. Reconciling against everything that actually went out on a channel, whoever posted it, needs livePosts=true.

Last updated on