Skip to content

Support Instagram collaborators on Reels/feed posts #213

Description

@kamol1dn

What

Instagram's Content Publishing API accepts a collaborators parameter when creating a media container. TryPost doesn't expose it, so posts published through TryPost can't invite collaborators — which for us means doing it by hand on every single Reel.

Why it matters

We publish a podcast (On The Ground) and our client requires both co-hosts to be invited as collaborators on every Instagram Reel. It's a condition of the engagement, not a nice-to-have.

We schedule ~14 clips a week through TryPost. Every one of them currently needs someone to open the Instagram app after it publishes and re-invite the same two accounts. That's 14 manual interventions a week on posts that are otherwise fully automated — and it's the single reason our pipeline isn't hands-off.

Collaborator posts also surface on each collaborator's profile and feed, so this is the difference between one account's reach and three. Any team posting on behalf of a multi-host show or a brand partnership hits the same wall.

The API shape

Container creation takes an array of usernames:

POST https://graph.facebook.com/{ig-user-id}/media
  media_type=REELS
  video_url=...
  caption=...
  collaborators=["username1","username2"]

Supported on Reels, single images and carousels. Not supported on Stories.

Notes from Meta's docs worth encoding:

  • Max 3 collaborators per post.
  • Private accounts can't be tagged as collaborators via the API.
  • Invited users get a request and must accept; until they do, the tag isn't public. So a successful publish does not mean the collaborator is live — worth reflecting in any UI copy so users aren't confused.
  • There's a companion endpoint that returns invite status (Accepted / Pending / Declined), which would make a nice follow-up but isn't needed for v1.

Suggested scope

Smallest useful version — accept the field and pass it through:

  1. app/Support/PostPlatformMetaRules.php — add an Instagram key alongside the existing aspect_ratio. Something like:

    // Instagram / Facebook
    'platforms.*.meta.aspect_ratio' => ['sometimes', 'nullable', 'string', Rule::enum(AspectRatio::class)],
    'platforms.*.meta.collaborators' => ['sometimes', 'nullable', 'array', 'max:3'],
    'platforms.*.meta.collaborators.*' => ['string', 'max:30'],
  2. app/Services/Social/InstagramPublisher.php — thread it into the container payload in publishReel() (and publishFeed() / publishSingleImage() if you want parity). publishStory() should ignore it, since Stories don't support collaborators.

  3. Surface it in the composer UI and in the API/MCP docs for platforms[].meta, next to TikTok's privacy_level and Pinterest's board_id.

Error handling: Instagram rejects the container when a username is invalid or private. InstagramPublishException already maps Meta error codes, so it'd be worth mapping that case to a clear "collaborator X can't be tagged" rather than a generic failure.

Happy to help

We're on TryPost Cloud and hit this every week. If a PR would be welcome, we can put one up against these three files — just let us know whether you'd want the status-check endpoint in the same change or kept separate.

Activity

  1. paulocastellano commented on Jul 29, 2026

    @paulocastellano
    Contributor

    Make sense, you are able to create a pull request for that ?

  2. HafizMMoaz commented on Aug 17, 2026

    @HafizMMoaz
    Contributor

    Thanks for the detailed writeup - the suggested scope made this straightforward. Opened #289 covering the "smallest useful version": platforms.*.meta.collaborators validation (array, max 3, matches your suggested shape) and InstagramPublisher threading it into the container that actually gets published - single image, Reel, or the carousel's parent container (not per-item children, which Instagram doesn't accept it on). Stories are untouched since Instagram ignores it there.

    Two things from your writeup I deliberately left out, noted in the PR:

    • Composer UI: would be the first real use of this app's TagsInput primitive (everywhere else needing an array-of-strings field uses server-side autocomplete instead), and I have no way to verify it in a browser in this environment - didn't want to ship an unverified new UI pattern. The feature works today via API/MCP; UI surfacing feels right as a follow-up.
    • Error-code mapping: didn't add a guessed error_subcode for invalid/private usernames since I don't have a confirmed one from Meta's docs - the existing fallback already surfaces Meta's own error_user_msg when present.

    Status-check endpoint and docs site are out of scope per your own note. Tests passing (105), Pint clean.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions