今天，我們要把 Day15 的 Meta 三件套 與 Day16 的 閱讀 API 文件 結合起來，將原本的「圖文工作流」升級成「影片版本」。在這過程中，你可能會遇到兩個常見的錯誤：

1. Supabase 上傳時出現重複檔案（duplicate）
2. IG 或 Threads 的 container 尚未完成（not ready）

今天的重點，就是透過閱讀 API 文件去設計節點來解決這兩個問題，打造更穩定可靠的影片上傳流程。（要用到的技能包含 If 節點 與 HTTP Request 節點）

不過，這篇文章和之前不太一樣：我不會直接把完整設定放上來，而是提供 相關文件與節點排序。算是一個小挑戰，希望你能試著透過閱讀 API 文件與觀察工作流邏輯，自己先推導出解法。

一、 修改節點參數：把圖文改成影片

• 關鍵：如何讓原本的發圖文工作流，支援影片上傳？
• 思考：先想想看有哪些節點會受到影響?
  • 不受影響 : 取得檔案、下載檔案、上傳到 supabase 、取得 URL 節點
  • 受影響 : 主要是上傳到平台的節點
• FB 粉專 : FB 的圖文發佈非常簡單，但影片就完全不同了。
  根據官方文件，粉專發影片需要透過 video_file_chunk，而且還要走「兩步驟流程」：
  (1)準備上傳 (2)正式上傳，最後才發布到貼文
  官方文件截圖如下：

粉專發影片需要有 video_file_chunk ，而要取得 video_file_chunk 需要有兩個步驟：（１）準備上傳（２）正式上傳
這部分我今天還沒跑通，但明天的「下集」我會分享完整解法，包含 FB 以及 YouTube 的影片發佈設定。

• IG : container 的設定需要調整(官方文件截圖如下)
  

• 修改方式：

  1. IG 在產生 container 時，需調整 media_type 為 REELS、image_url 參數改為 video_url 參數並放入影片的連結
  2. IG 在發布 container 時，要把Graph API 節點中的 Host URL 從 default 改成 Video uploads

• Threads :
  

• 修改方式：

  • Threads 在在產生 container 時，需調整 media_type 為 VIDEO、image_url 參數改為 video_url 參數並放入影片的連結

二、解決 Supabase 重複檔案 (duplicate)

• 關鍵：如果上傳時檔案已存在，Supabase 會報 duplicate 錯誤。
• 思考：要在工作流中，先檢查檔案是否已經存在。

解法：

1. 直接上傳 → 如果回傳 duplicate，表示已存在 → 改成直接取得 URL。
2. 或先嘗試取得 URL → 如果失敗，表示尚未上傳 → 再進行上傳。
3. 可用 If 節點判斷檔案狀態。

我的做法是：先上傳，再根據結果決定是否改用已存在的 URL。

• 邏輯：先確認是否存在，存在的話直接獲取連結，不存在的話才上傳再取得ＵＲＬ

三、解決 IG / Threads Container Not Ready

• 關鍵：有時候 container 雖然成功建立並回傳 ID，但一發布就報錯。
• 原因：影片檔案較大，打包成 container 需要時間，如果立刻 Publish，就會失敗。

實作方法：

1. 使用 HTTP Request 節點查詢 container 狀態。
2. 如果未完成，就等待一段時間後再檢查一次（Loop）。
3. 確保影片在完成打包後才發佈。

四、結語與明日預告

今天，我們嘗試著把「圖文工作流」挑戰升級成「影音工作流」，並且透過 Debug 學會了：

• 參考官方 API 文件，修改節點參數支援影片上傳
• 避免 Supabase 重複檔案錯誤
• 確保 IG/Threads 的 container 完成後再發佈

這就是自動化的真實樣貌：不是一次設定好就萬事 OK，而是持續 Debug，讓流程從「能跑」變成「更穩」。

今天的內容偏向「思路拆解與挑戰題」，我沒有把所有設定細節一次放完，是希望你能先動手試試看。

如果卡住也別擔心，因為明天的「下集」我會公開完整設定流程，並且補上 FB 與 YouTube 的影片版本。

我們明天見！