Instagram Reels API share_to_feed: true does not guarantee Reels
share_to_feed=true lets a Reel appear in Feed and Reels; false limits it to Reels. Neither value guarantees placement. What Meta's page says, and what to prep.

share_to_feed only widens or narrows where a Reel may appear. Meta's IG User Media reference says that when it is true, the Reel can appear in both the Feed and Reels tabs, and when false it can appear only in the Reels tab. It adds that neither value decides whether the Reel actually shows in the Reels tab, because the Reel may not meet eligibility criteria or may not be selected by the algorithm (read 2026-10-02).
The field is Reels only. It is part of the container request, not the file, so nothing in Sume's output sets it; Sume's job is to give you a file that meets the spec Meta links to.
What does each value do?
The reference lists share_to_feed twice in the Reel container syntax. Send it once.
| Value | Where the Reel can appear | Guarantee |
|---|---|---|
| true | Feed and Reels tabs | None for the Reels tab |
| false | Reels tab only | None for the Reels tab |
| Omitted | Not stated on the page | Not stated |
What decides whether a Reel reaches the Reels tab?
The page points to the Reel specifications for eligibility criteria: MOV or MP4 with no edit lists and the moov atom at the front, AAC audio, HEVC or H264, 23 to 60 FPS, 3 seconds minimum and 15 minutes maximum, 300 MB maximum, and a recommended 9:16 shape. Meeting them is necessary; the algorithm's selection is outside the API.
Video inspect probes duration_seconds, fps, container, video_codec, audio_codec and size_bytes, so most of that list can be checked before you create a container. It does not report edit lists or the moov position.
What does sharing to the feed change about the file?
The cover. When a Reel is shared to the feed, Meta crops the cover to the middle 1:1 square, as described in the reference's cover specification. A 9:16 cover therefore loses its top and bottom in the feed, so keep the subject in the middle third.
# Container request with share_to_feed=false (Reels tab only).
# IG_USER_ID, IG_TOKEN and VIDEO_URL are yours; VIDEO_URL must be fetchable without login.
curl -X POST "https://graph.facebook.com/v26.0/$IG_USER_ID/media" \
-d media_type=REELS \
-d "video_url=$VIDEO_URL" \
-d share_to_feed=false \
-d "access_token=$IG_TOKEN"What should I do?
Set share_to_feed deliberately, check the file against the spec list first, and do not report a Reel as "in the Reels tab" just because the container published. Look at the live account.
Sources
Related posts
More in Integrations
- Instagram Reels API limits: 3 collaborators, no carousel, audio tags
Meta's Reels API allows up to 3 collaborators, keeps Reels out of carousels, and limits music tagging to original audio. The limits that shape a batch plan.
- Lambda 1,000 concurrency and Sume webhook bursts finishing together
Jobs from one bulk queue often finish together. Lambda starts at 1,000 concurrent executions, lower on new accounts. Here is how Sume's retries absorb a burst.
- Lambda async 1 MB limit vs Sume's 1 MiB run webhook overflow
Lambda takes 1 MB for async events and 6 MB sync. Sume sends a run webhook inline up to 1 MiB, then payload null. Forward the id, not the receipt.
- langchain-mcp-adapters is archived: what changes for Sume
langchain-mcp-adapters was archived on Sept 17, 2026 and MCP moved into LangChain as langchain[mcp]. What to re-check when the server is Sume's hosted MCP.
Written by Sume