Instagram Graph API: "Media created with media_type=VIDEO is a carousel item" error even when using media_type=REELS

nao ! mescle tudo !
I’m seeing the exact same behavior today (Feb 26, 2026), and it looks like a Meta-side regression rather than an app-side bug. ✅
Symptom (matches your report)
- Step 1: /{ig-user-id}/media returns a creationid
- Step 2: container reaches statuscode=FINISHED
- Step 3: /mediapublish fails with subcode 2207089:
  “Media created with mediatype=VIDEO is a carousel item … use mediatype=REELS instead”
- Even though the container creation request explicitly sets mediatype=REELS.
What I validated to eliminate common root causes (so you don’t waste hours)
1) Video URL “ingestion readiness” (server/host is NOT the culprit in my case)
- Verified the final MP4 URL is truly public HTTPS.
- Verified the server supports byte-range requests (critical for Meta ingestion):
  - HEAD: returns 200 + Content-Type: video/mp4 + Content-Length present
  - Range: “Range: bytes=0-1” returns 206 Partial Content
  - Accept-Ranges: bytes present
  - No redirects (no 301/302 hops)
✅ Result: URL passes the usual ingestion checklist.
2) Host/interstitial avoidance
- Tested with a tunnel/provider that does NOT inject interstitial HTML pages or “browser warning” screens.
- Also tested with a plain static hosting URL.
✅ Result: Still reproduces the downgrade → publish failure.
3) “Virgin” synthetic video test (rules out file metadata/encoding/copyright flags)
- Generated a brand-new 3–5s MP4:
  - H.264 baseline/main
  - no audio
  - minimal metadata
✅ Result: Still fails with the same 2207089 pattern.
4) Request format matrix (rules out body encoding quirks)
I tested container creation + publish using:
- multipart/form-data
- application/x-www-form-urlencoded
- application/json
✅ Result: Same failure pattern across formats.
5) API version matrix (rules out “just downgrade/upgrade”)
- Tested multiple Graph versions (older and newer)
✅ Result: Version-agnostic in my reproduction.
6) Token matrix + linkage sanity checks (rules out wrong token/scopes/IG linkage)
- Confirmed the token is valid and has instagramcontentpublish.
- Confirmed the IG business account ID used for publishing matches the linked asset from the business/page side.
- Tested both user token and page token scenarios (where applicable).
✅ Result: Still reclassified.
7) Low-level transport sanity (rules out HTTP client “helpfulness”)
Because Node/modern clients may add Transfer-Encoding: chunked (and other “smart” behavior), I also tried bypassing normal HTTP libraries:
- Constructed the request in a low-level way (no Axios/Fetch), to ensure headers/body weren’t being mutated.
✅ Result: The platform still behaved the same (container ends up treated as VIDEO internally).
Conclusion (what this strongly suggests)
- Meta is accepting the request, but their backend is silently storing the container as VIDEO (carousel item) even when mediatype=REELS is provided.
- That’s why /mediapublish rejects it: standalone VIDEO containers can’t be published as a single post, so you get 2207089.
- Since the same behavior reproduces with a “perfect” MP4 URL (206 Range) and with synthetic media, it points to a server-side regression.
Practical workaround (keeps production running) 🧯
- Catch subcode 2207089 on publish.
- Automatically fall back to publishing a PHOTO post (e.g., video thumbnail or a companion image) with the same caption.
- This avoids a “hard fail” while Meta fixes Reels ingestion.
Note: I also tested posting the same content as an IMAGE/PHOTO flow, and that path succeeds reliably (which further supports that the Reels/Video ingestion path is what’s currently broken).
If others want to validate quickly
- Run the 206 Range check against your videourl.
- Try a 3–5s synthetic MP4 with caption “test”.
- If 2207089 still happens after FINISHED, you’re likely hitting the same Meta regression.
If you’re reporting this to Meta
- Include that the videourl supports 206 byte-range.
- Include that synthetic MP4s also fail.
- Include that the container reaches FINISHED but is treated as VIDEO at publish time.
To help get this fixed faster, I’d strongly encourage everyone affected to file an official Meta bug report and include the exact reproduction details above.
✅ Report it here (Meta bug tool):
https://developers.facebook.com/support/bugs/
When you report, please include:
- Error: code=100, subcode=2207089 (“Carousel Item Cannot Be Published Standalone”)
- That you sent: mediatype=REELS + videourl + sharetofeed=true
- That the container reaches: statuscode=FINISHED
- That publish still fails and the container appears to have been saved internally as VIDEO
- Proof your videourl is ingestion-ready:
  - HEAD returns 200 + Content-Type: video/mp4 + Content-Length
  - Range request returns 206 + Accept-Ranges: bytes
- That the issue reproduces even with a synthetic 3–5s MP4 (H.264, no audio)
- Tested across multiple Graph API versions and request encodings (json / x-www-form-urlencoded / multipart)
📌 Tip: If multiple devs submit reports with the same subcode + “FINISHED but downgraded to VIDEO”, Meta is more likely to escalate it quickly.
If you want, you can paste this one-liner into your report title:
“IG Graph API regression: mediatype=REELS containers get stored as VIDEO; /mediapublish fails with 2207089 even with 206 Range-capable MP4”

Oh my god, I've been working on this problem for 5 hours. I've rewritten all my code and run tests every which way.

Thank you so much for your message.