在上一篇教學中，我們介紹了 如何透過 Facebook Graph API 自動發布多圖貼文。今天，我們將進一步把自動化版圖擴展到 Instagram (IG)。 透過 n8n、Instagram Graph API，並結合 Cloudinary 作為圖片的公開圖床，我們可以打造一套「一鍵自動多平台發文」的系統。這篇文章將帶你拆解整個 n8n 工作流程，並一步步完成必要的 API 權限申請。 系統運作流程解析：IG 自動發文的底層邏輯在正式動手之前，我們先理解 n8n 節點的運作邏輯。要透過 API 發布 IG 貼文，流程如下： 表單提交 (Form Submission)： 接收要發布的文字內容與圖片檔案。 圖片檢查與圖床轉換： IG API 嚴格規定，圖片必須是一個「公開可存取的網址 (Public URL)」。因此，我們必須先將圖片上傳至 Cloudinary 以取得公開網址。 建立 Instagram 容器 (Create Container)： 根據 Meta 官方內容發佈文件，我們需要先用圖片網址與貼文內容建立一個 Media Container。 等待緩衝 (Wait)： 設定約 30 秒的緩衝時間，避免 Meta 伺服器處理過慢導致後續請求失敗。 正式發佈 (Publish)： 獲取 Container ID 後，執行最終的發佈動作。 延伸閱讀： 更詳細的 n8n IG API 串接原理，可參考 n8n Instagram API 實戰指南。 步驟一：如何設定 Meta 開發者應用程式與取得 IG 權杖？要讓系統代為發文，我們必須先在 Meta 開發者平台申請專屬的應用程式與存取權杖 (Access Token)。 1. 建立 Meta 應用程式前往 Meta 開發者應用程式介面 (Apps)： 點擊「建立應用程式」，選擇「其他」>「企業商家」。 填寫應用程式名稱（例如：n8n-ig-auto-post）與聯絡信箱。 2. 設定隱私權政策網址為了讓應用程式能順利上線，Meta 要求提供隱私權政策網址： 可利用免費工具 PrivacyPolicies.com 快速生成一份基本的隱私權條款。 將生成的專屬網址複製，貼回到 Meta 應用程式的「基本資料 > 隱私權政策網址」中並儲存。 將應用程式狀態切換為 「上線 (Live)」。 3. 新增 Instagram 測試人員與轉換專業帳號由於應用程式尚未經過繁瑣的官方審查，我們需要將自己的 IG 帳號加入「測試人員」： 在 Meta 後台左側選單進入「應用程式角色 > 角色」。 新增「Instagram 測試人員」，輸入你的 IG 帳號。 重要提醒： 你的 IG 帳號必須切換為 「專業帳號 (商業或創作者)」，否則無法透過 API 發文！ 打開手機 IG App，進入「設定 > 網站權限 > 應用程式和網站 > 測試人員邀請」，點擊「接受」。 4. 取得 Access Token 與 IG ID 回到 Meta 開發者後台，設定「Instagram 圖形 API」。 使用「圖形 API 測試工具 (Graph API Explorer)」。 勾選所有與 instagram_manage_* 及 instagram_content_publish 相關的權限。 點擊「Generate Access Token (產生存取權杖)」，並將這串落長的 Token 複製保存。 同時記下你的 Instagram ID，這兩個值將會填入 n8n 的設定中。(註：測試用的 Token 預設有效限期約為 2 個月，過期需重新產生。) 步驟二：為什麼需要 Cloudinary？如何設定免憑證上傳？如前所述，IG Graph API 不接受直接傳送本機圖片，只接受公開網址。我們使用 Cloudinary 來做自動化圖床。 1. 取得 Cloud Name登入 Cloudinary 控制台，在 Dashboard (儀表板) 找到你的 Cloud Name，這會是 n8n API 呼叫的基礎路徑。 2. 設定 Unsigned Upload Preset (無簽章上傳預設)在設定自動化時，為了安全性與便利性，我們 不使用 API Key 與 API Secret，而是改用 Upload Preset Name。 進入 Cloudinary 的「Settings > API Keys > Upload」。 點擊「Add Upload Preset」。 將 Signing mode 設定為 Unsigned。 設定一個你專屬的 Upload preset name (例如：n8n-try-2026)，並設定要存放的資料夾名稱 (Folder)。 儲存後，將這個 Preset Name 複製下來。 為什麼不直接使用 API Key？將 API Secret 寫死在前端或簡單的工作流中存在資安風險。Unsigned Upload Preset 允許你在不暴露核心密鑰的情況下，讓系統把檔案上傳到指定資料夾，是自動化流程中最推薦的簡化做法。詳情可參考這篇探討：為何 n8n 教學愛用 Cloudinary Upload Preset？安全與便利的平衡。 步驟三：整合 n8n 節點並執行測試最後，我們回到 n8n 介面，將剛剛取得的參數填入對應的資料表或節點中： Cloudinary 節點設定： 將 Cloud Name 與 Upload Preset Name 填入。 Instagram 節點設定： 將 IG ID 與 Access Token 填入 Authorization 欄位。 觸發流程： 打開 n8n 的表單提交 (Form Trigger)，上傳一張圖片並輸入測試文字。 驗證結果： 執行流程後，打開你的 Instagram 頁面，就可以看到圖片已經成功透過 n8n 自動發布了！ 常見問答 (FAQ)Q：為什麼流程執行成功，但 IG 上卻沒有出現貼文，或出現權限錯誤？A：這通常是最常見的設定問題，建議依序檢查以下幾項： 你的 IG 帳號是否已切換為 專業帳號（創作者或商業）。 該 IG 帳號是否已正確加入 Meta App 的 Instagram 測試人員，並且已在手機上接受邀請。 產生 Access Token 時，是否有勾選 instagram_content_publish、instagram_basic 等必要權限。 你的 IG 是否有正確綁定對應的 Facebook Page。許多 Meta API 權限是透過粉專與商業資產關聯來驗證的。 如果以上都確認無誤，建議回頭檢查 n8n 的 HTTP Request 回傳內容，Meta 通常會在錯誤訊息中直接指出是權限不足、帳號資格不符，還是參數格式有問題。 Q：為什麼圖片已經上傳到 Cloudinary，但 Instagram API 還是說 image_url 無效？A：因為「有網址」不等於「符合 IG API 可讀取的公開網址」。你需要確認： 該圖片網址可以在 無痕模式 直接開啟，不需要登入、不會跳轉、也不會出現權限限制。 網址指向的是 實際圖片檔，而不是預覽頁、下載頁或帶驗證機制的暫時連結。 圖片格式為常見可支援格式，例如 jpg 或 png。 圖片尺寸與比例不要過於極端，避免 Meta 在建立容器時失敗。 最穩定的做法，就是使用 Cloudinary 上傳後取得的 secure_url 當作 image_url，不要自行拼接其他可能會失效的連結。 Q：為什麼流程中要加 Wait 節點？可以直接建立容器後馬上 Publish 嗎？A：理論上可以連續呼叫，但實務上不建議。因為 Meta 在建立 Media Container 後，還需要一點時間處理圖片內容；若你太快發送 Publish 請求，就可能出現容器尚未就緒、發文失敗，或偶發性的 API 錯誤。 因此在 n8n 中加入約 20 到 30 秒的 Wait，是一種很常見也很實用的穩定化做法。如果你想再更精準一些，也可以改成輪詢 Container 狀態，確認處理完成後再執行 Publish。 Q：這套流程可以直接發 Reels、限時動態或多張輪播貼文嗎？A：這篇教學的流程主要針對 單張圖片貼文。若你要發： 輪播貼文：通常需要建立多個媒體項目，再組成 Carousel Container，流程會比單張圖複雜。 Reels：需要改用影片上傳與對應的發佈流程，參數與等待時間也不同。 限時動態：支援情況與發佈方式需依 Meta API 當前規範確認，不能直接套用一般貼文邏輯。 也就是說，這篇文章適合作為「IG 自動發文入門版」，如果你後續要延伸到更多貼文型態，建議再額外拆成不同 workflow 來做。 Q：Cloudinary 的 Unsigned Upload 安全嗎？會不會被別人亂傳圖片？A：Unsigned Upload 本質上是只要知道 Preset Name 就能上傳，因此有一定風險。但你可以透過 Cloudinary 後台針對該 Preset 設定「檔案格式限制」、「檔案大小限制」甚至是「上傳後轉檔規則」，來避免遭惡意濫用。對於個人自動化用途而言，比起洩漏 API Secret，這是相對安全且輕量的做法。 如果你是要提供給團隊或正式商業場景使用，建議再往前一步： 將上傳來源限制在特定流程或後端。 規劃專用資料夾，方便管理與清理。 定期輪替 Upload Preset，避免長期暴露固定入口。 監控 Cloudinary 使用量，避免異常流量造成額外成本。 Q：我的自動發文系統突然失效了，發生了什麼事？A：最可能的原因是 Meta Access Token 過期。透過 Graph API 測試工具生成的 Token 通常只有 60 天左右的效期。若要長期自動化，建議在到期前透過 API 延長權杖效期，或是定期手動重新生成一次並更新至 n8n 中。 除了 Token 之外，也建議同步檢查： Meta App 是否仍維持上線狀態。 測試帳號是否仍保有測試人員身分。 Cloudinary Preset 是否被修改、停用或刪除。 n8n 中的節點參數是否被其他人誤改。 Q：這套流程適合正式營運使用嗎？還是只適合測試？A：可以用於正式營運，但前提是你要把它從「可跑」升級成「可維護」： 權杖更新機制要制度化，不能等過期才手動補救。 n8n 流程要加上錯誤通知，例如失敗時寄 Email、發 Slack 或 LINE Notify。 圖片、文案、發文時間最好有資料表或資料庫可追蹤。 若有多人使用，建議加入審核機制，避免錯發或重複發文。 如果你只是個人品牌、小型工作室，這篇教學已足夠作為第一版；但若你是企業團隊，後續應把監控、權限管理與例外處理一併補上。 Q：如果我想把這個流程擴充成「一鍵同步發 Facebook + Instagram」，要怎麼做？A：這正是 n8n 很適合發揮的地方。你可以把「表單輸入」或「內容資料表」當成單一來源，接著分流到不同平台節點： 一條流程處理 Cloudinary 圖片上傳。 一條分支送往 Facebook Graph API。 另一條分支送往 Instagram Graph API。 最後把各平台回傳結果寫回 Google Sheets、Airtable 或 Notion。 這樣你就能把原本重複操作的社群發文，整理成一套真正可複用的多平台內容發布系統。

如果你正在找「n8n Facebook 多圖貼文教學」、「Facebook attached_media 怎麼設定」或「n8n 如何一次發布多張圖片到 Facebook」，這篇就是針對這些問題整理的實戰版本。 先前我們分享過如何透過 n8n 模板自動發布「單圖加單文」到 Facebook。今天這篇文章，我們將進一步把流程升級成一次發布多張圖片的 Facebook 貼文，並直接拆解多數人最常卡住的 attached_media、/photos 與 binary 判斷問題。 如果你還沒完成 Page ID、長期 Page Access Token 或單圖發文設定，建議先閱讀上一篇：n8n 串接 Facebook 自動發文教學：Meta API、Page ID、長期 Token 完整指南。 這篇文章可以把它理解成上一篇的進階版：前一篇解決「先發得出去」，這一篇解決「如何穩定改成多圖發文」。 如何在 n8n 表單中開啟多檔案上傳功能？在原本的預設模板中，表單 (Form) 節點僅支援單張圖片與一篇文章。若要實現多圖上傳，我們必須先從觸發器 (Trigger) 著手修改。 請進入 n8n 的 Form Trigger 節點，找到設定並勾選 Multiple Files 功能。開啟此選項後，表單就能一次接收多張圖片的輸入。為了確認功能正常運作，建議先進行測試，例如輸入標題「test 0403 多圖」並同時上傳三張圖片，藉此確認資料是否成功進入後續的工作流中。 破解 API 迷思：為什麼 Facebook Graph API 其實不吃 JSON？這是在串接 Facebook Graph API 時最容易踩到的坑！許多人在查閱 Meta 官方文件時，會看到官方範例給的都是 JSON 格式。然而，當你實際在 n8n 中將 Content-Type 設為 JSON 時，常常會遇到發文失敗或行為異常的狀況。 經過測試與 AI 的輔助分析，我們得出了一個重要結論：Facebook Graph API 預設其實是接收 url-encoded 與 form-data 格式，而非 JSON。 在 n8n 的 HTTP Request 節點中，最佳的實踐方式是： 主體內容 (Body)： 使用 form-urlencoded 模式，將 Token、Message 與整理好的 attached_media 傳送出去，這樣不僅容易發送，穩定度也最高。 圖片上傳 (Photo Upload)： 使用 form-data 的方式來傳送二進位 (Binary) 的圖片檔案。 請果斷放棄使用 JSON 格式來修改多圖貼文，直接採用 form-urlencoded 與 form-data，能幫你省下大量的除錯時間。 實戰解析：多圖貼文真正要改的是什麼？很多人第一次改 Facebook 多圖貼文時，會以為只要把 attached_media[0] 改成 attached_media[1]、attached_media[2] 就好。實際上不是這樣。 多圖貼文的核心不是「多加幾個欄位」，而是整個流程要改成先上傳圖片、再集中發文。 正確流程如下： 表單允許一次上傳多個檔案 把每張圖拆成獨立 item 每張圖各自呼叫 POST /photos，並設定為未發佈 收集每張圖回傳的 photo id 最後只呼叫一次 POST /feed，把所有 media_fbid 一起送進 attached_media 換句話說，你不是直接把多張圖片塞進同一次照片上傳請求，而是先把每張圖變成 temporary photo，最後再用一篇貼文把它們組起來。 最短版修改清單如果你手上已經有上一篇的單圖工作流，要改成多圖版，實務上先完成這 5 件事就夠了： Form Trigger 把 Multiple Files 改成 true 原本的「如果圖片不存在」條件，改成檢查 Object.keys($binary ?? {}).length === 0 新增一個 Code 節點，把多張圖片展開成多個 item 新增一個 Code 節點，把所有 photo id 整理成 attached_media 最後發文的節點，把 attached_media[0] 改成整個 attached_media 陣列 如果你是用既有模板直接改，這 5 項通常就是變更範圍的 80%。剩下的問題，多半都是權限、Graph API 版本，或請求格式設定錯誤。 多圖上傳的資料處理與判斷邏輯1. 先展開圖片，再逐張上傳表單收到多張圖片後，n8n 內部通常不會直接變成多筆獨立資料，而是先包在同一個輸入裡。這時要先新增一個節點，把圖片展開成一張圖一個 item，後面的 Facebook 上傳節點才能逐張處理。 這一步的重點不是「看起來有三張圖」，而是流程裡真的要變成三個可迭代的 item。只有這樣，後面的 POST /photos 才能對每張圖各自拿到一個 photo id。 2. 每張圖都先走 POST /photosFacebook 多圖貼文不是直接把多張 binary 一次送到 /feed。正確做法是每張圖先打一次 /{page_id}/photos，並設定為不立即發佈，讓 Facebook 先建立暫存照片。 等每張圖都成功回傳 ID 之後，才進到最後一個發文節點。這也是很多人一直測不通的原因，因為他們跳過了「先建立 temporary photo」這一步。 3. 最後一次把所有 media_fbid 組回 attached_media當你拿到多張圖的 photo id 後，接下來不是再一張一張發貼文，而是把所有 ID 整理成 Facebook 要的格式，例如： 12345[ { "media_fbid": "photo_id_1" }, { "media_fbid": "photo_id_2" }, { "media_fbid": "photo_id_3" }] 最後只呼叫一次 POST /feed，並把整包 attached_media 傳出去，這樣 Facebook 才會把它視為同一篇多圖貼文。 4. 「是否有圖片」的判斷邏輯也要一起改單圖流程常見的寫法，通常是假設只有一個固定欄位，例如 binary.data 或某個指定圖片名稱。但多圖流程下，這種判斷很容易失準，因為二進位檔案不再只有單一鍵值。 比較穩的做法，是直接檢查目前是否真的存在任何 binary 檔案： 12345if (Object.keys($binary ?? {}).length === 0) { // 沒有圖片，走純文字貼文流程} else { // 有圖片，走圖片上傳與多圖發文流程} 這段寫法的好處是，不需要綁死某個圖片欄位名稱，對單張圖、多張圖、甚至沒有圖片的情境都比較穩。 可直接參考的 Code Node 範例如果你想更快落地，下面這兩段可以作為 Code 節點的參考起點。實際欄位名稱還是要依你的工作流資料結構微調，但核心思路就是這樣。 範例 1：展開多張圖片這個節點的目的是把同一筆輸入裡的多張 binary 圖片，拆成多個 item，讓後面的 POST /photos 可以逐張執行。 1234567891011121314const binaryEntries = Object.entries($binary ?? {});return binaryEntries.map(([key, file]) => { return { json: { ...$json, binaryKey: key, fileName: file.fileName ?? key, }, binary: { [key]: file, }, };}); 這段的重點是： 先用 Object.entries($binary ?? {}) 取出所有圖片 每張圖各自回傳成一個 item 保留原本的 $json，避免後面發文文案或其他欄位不見 範例 2：整理成 attached_media當每張圖片都上傳到 POST /photos 後，Facebook 會回傳各自的 id。接下來就要把這些 id 整理成最後發文節點要吃的格式。 12345678910111213const attached_media = $input.all().map((item) => { return { media_fbid: item.json.id, };});return [ { json: { attached_media, }, },]; 如果你的最後一個發文節點還需要貼文文字、Page ID 或其他欄位，就記得在這裡一起帶回去，不要只剩 attached_media。 最後發文節點要注意什麼？整理完之後，最後一個 POST /feed 節點要送的，不再是單一的 attached_media[0]，而是整包 attached_media。也就是說，這一步的重點不只是欄位名稱改掉，而是前面的資料形狀已經從單張圖邏輯，變成多張圖陣列邏輯。 跨平台自動發文的策略與考量在學會了 Facebook 多圖發文後，你可能會想：「我能不能把這個多圖工作流直接套用到 Instagram、Threads、X (Twitter) 或 LinkedIn 上？」 這裡要特別提醒，每個社群平台的 API 設計與支援度皆不相同。Facebook 接受的 attached_media 多圖陣列格式，放到其他平台可能會導致報錯。如果你追求的是「一鍵同時發布到所有平台」，那麼維持「一圖一文」會是最安全、兼容性最高的方式。 然而，如果你是為了深入學習 API 串接與自動化邏輯，強烈建議你親手實作一次專屬於 Facebook 的多圖發文流程。這能幫助你透徹理解 API 格式的差異、陣列資料的轉換，大幅提升你的 n8n 實戰能力！ 常見問答 (FAQ)Q：多圖貼文是不是只要多加幾個 attached_media[1]、attached_media[2] 就可以？A：不行。這是最常見的誤解。Facebook 多圖貼文的重點不是多塞幾個欄位，而是要先讓每張圖各自上傳成未發佈照片，再把所有 photo id 組成 attached_media 後一次送進 POST /feed。如果你只是在原本單圖節點上多加幾個欄位，通常流程會不穩，或根本不會被 Facebook 正確識別成同一篇多圖貼文。 Q：在 n8n 裡，正確的多圖發文順序是什麼？A：最穩的順序是這樣： 表單開啟多檔上傳 將多張圖展開成多個 item 每張圖各自呼叫 POST /photos 收集所有回傳的 photo id 最後呼叫一次 POST /feed，把所有 media_fbid 傳進 attached_media 如果你的流程不是這個順序，通常就是之後會卡住的地方。 Q：為什麼我照著官方文件用 JSON 傳多圖，還是一直失敗？A：因為官方文件的範例格式，不代表在 n8n 裡就是最穩的做法。實務上，Facebook Graph API 在這類發文情境下，通常用 application/x-www-form-urlencoded 與 multipart/form-data 會更穩。簡單說： 圖片上傳用 form-data 最後發文用 form-urlencoded 如果你整段流程都硬用 JSON，常見結果就是欄位格式對了，但請求仍然失敗，或 Facebook 不照你預期解析。 Q：為什麼「是否有圖片」這個判斷在多圖版容易壞掉？A：因為單圖流程通常只檢查某一個固定欄位，例如 binary.data。但多圖上傳時，binary 的結構不一定只會有單一鍵值，所以原本那種寫死欄位名稱的判斷方式常常會失準。比較穩的寫法是： 1Object.keys($binary ?? {}).length === 0 這樣你判斷的是「現在到底有沒有任何圖片檔」，而不是賭某個欄位名稱剛好存在。 Q：表單已經開了 Multiple Files，為什麼還是不能直接發多圖？A：因為 Multiple Files 只解決「前端可以一次上傳多張圖」，沒有幫你完成後面的資料整理。你還是得自己把圖片展開、逐張上傳、收集 ID、再整理成 attached_media。也就是說，表單只是入口，多圖貼文能不能成功，關鍵仍然在後面的工作流設計。 Q：多圖流程測試時，最少要驗證哪些情境？A：至少要測這 3 種： 沒有圖片，只發純文字 只有 1 張圖片 一次上傳多張圖片 如果這三種都能正常執行，代表你的條件分流、binary 判斷、圖片上傳與最後發文邏輯大致是穩的。只測「三張圖剛好成功一次」其實不夠，因為很多錯誤都發生在無圖或單圖情境切換時。 Q：如果我要沿用上一篇單圖模板，最少要改哪些地方？A：最小修改範圍就是本文前面那 5 項： Form Trigger 開啟 Multiple Files 調整「是否有圖片」判斷 新增圖片展開節點 新增 attached_media 整理節點 把最後發文欄位從單一 attached_media[0] 改成整個 attached_media 你可以把它理解成：前面多了一段「圖片預處理」，最後一段則從「單圖發文」改成「多圖組裝後發文」。 Q：如果發文節點一直報權限錯誤，是多圖流程寫錯了嗎？A：不一定。多圖流程錯誤與權限錯誤是兩件事。如果你看到的是 OAuth、permission、scope 相關訊息，通常先檢查的不是 attached_media，而是： 你現在用的是不是正確的 Page Token 權限是否包含 pages_manage_posts Page ID 是否對應到同一個粉專 這類問題比較接近授權設定，而不是多圖組裝本身。需要的話可以回頭對照上一篇的 Token 教學一起排查。 Q：這篇流程可以直接套到 Instagram 或其他平台嗎？A：不建議直接照搬。這篇的重點是 Facebook Page 的多圖貼文流程，而 attached_media 這種組法本身就帶有平台特性。若你是做跨平台自動發文，最穩的策略通常還是先維持「一圖一文」，再依各平台 API 能力逐一擴充，而不是假設 Facebook 的多圖格式能通用。 參考資料 Meta Developers：Page Posts 上一篇：n8n 串接 Facebook 自動發文教學

如果你正在找「n8n 串接 Facebook 自動發文教學」、「Facebook Page ID 怎麼找」或「Meta 長期 Token 怎麼拿」，這篇就是針對這些問題整理的實戰指南。 在這篇教學中，我們將探討如何利用 n8n 工作流自動化工具，串接 Facebook Graph API，實現粉絲專頁的一鍵自動發文功能。 如果你不想從零開始刻節點，本篇教學將會使用由（Darks）開源提供的多平台自動發文模板進行示範，並專注解決串接過程中最容易卡關的 Meta 應用程式建立與 長期 Access Token 獲取。 你可以把這篇文章理解成一份實戰排雷手冊：不是只告訴你「理論上可以串接」，而是直接處理多數人在實作時最常遇到的三個問題： Token 很快失效，導致昨天能發、今天不能發 Meta 權限沒有勾完整，n8n 執行後直接報錯 模板本身可用，但一到自己的帳號與粉專環境就卡住 只要你把 Page ID、長期 Page Access Token、HTTP 節點版本 這三件事設定正確，Facebook 自動發文流程通常就能穩定跑起來。 n8n 串接 Facebook 自動發文前，你需要先準備什麼？在開始設定之前，你至少要先備好以下 4 個元素： 一個可正常登入的 n8n 環境 一個你有管理權限的 Facebook 粉絲專頁 一個 Meta for Developers 應用程式 可用於發文的 Facebook Page ID 與長期 Page Access Token 如果這四個條件都具備，後面的設定會順很多；如果少其中任何一項，通常就會卡在權限、授權或 endpoint 錯誤。 如何快速導入 n8n 自動發文模板？1. 取得並匯入工作流模板你可以前往 n8n 官方 Templates 庫 或創作者 Darks 的 Portaly 頁面 獲取一鍵自動發文模板。 作法： 複製模板內容後，直接在你的 n8n 畫布上按下 Ctrl+V (或 Cmd+V) 即可貼上完整的工作流。 2. 設定社群金鑰 (Data tables)在新版的 n8n 中，我們可以使用 Data tables 來集中管理各個社群平台的 API 金鑰，取代過去分散在各個節點填寫的麻煩。 在 n8n 左側選單點擊 Data tables，選擇 Create data table。 將表格命名為 社群金鑰（若使用模板，請務必與模板預設名稱完全一致）。 新增所需欄位（例如：main_scope、attribute、value）。 針對 Facebook 發文，我們至少需要準備並填入兩項核心資料： Facebook Page ID Facebook Access Token 接下來，我們將進入 Meta 開發者後台，去獲取這兩項關鍵資料。 如何建立 Meta 開發者應用程式，讓 n8n 可以串接 Facebook？要透過 API 發文到 Facebook 粉絲專頁，你必須先在 Meta 建立一支應用程式來取得權限。 1. 新增應用程式 前往 Meta for Developers。 點擊右上角的 建立應用程式。 應用程式類型請選擇 「商家 (Business)」 或 「其他 → 商家」。 輸入易於辨識的名稱（例如：n8n-fb-autopost），並填寫聯絡電子郵件。 2. 解決「隱私權政策」網址要求建立應用程式後，前往 應用程式設定 → 基本資料。系統會要求填寫「隱私權政策網址 (Privacy Policy URL)」才能將應用程式狀態切換為「上線」。 專家建議： 如果你沒有個人網站的隱私權頁面，可以使用免費的 Privacy Policy Generator 生成一份公版隱私權條款，獲取連結後貼回 Meta 後台即可過關。 3. 將應用程式切換為「上線」模式在基本資料設定完成並儲存後，務必將應用程式頂部的狀態由「開發中」切換為 「上線」，這樣 n8n 才能順利調用 API。 如何取得 Facebook 長期 Access Token 與 Page Token？這是整個流程中最容易出錯的環節。預設取得的 Token 通常只有 1 小時的壽命，我們必須將其轉換為「粉絲專頁專用的長期 Token」。 第一步：取得短期 User Token 在 Meta 開發者後台，點擊頂部選單的 「工具」→「圖形 API 測試工具 (Graph API Explorer)」。 右側面板設定： Meta 應用程式：選擇你剛建立的 App。 用戶或粉絲專頁：選擇 「取得粉絲專頁存取權杖」，並授權勾選你的粉絲專頁。 新增權限 (Permissions)： 這是發文成功的關鍵，請務必加入以下 5 個權限： pages_show_list pages_read_engagement pages_read_user_content pages_manage_posts pages_manage_engagement 點擊 Generate Access Token（產生存取權杖），並複製這串短效期金鑰。 第二步：轉換為長效期 Token 在「圖形 API 測試工具」中，點擊上方的 「存取權杖偵錯工具」 或點擊權杖旁的「i」圖示展開詳情。 點擊底部的 「延伸存取權杖 (Extend Access Token)」，取得約 2-3 個月效期的長期 User Token。 關鍵轉換： 我們需要將 User Token 換成 Page Token。回到圖形 API 測試工具，在 GET 請求欄位輸入以下端點（請替換為你的粉絲專頁 ID）：1/{你的粉絲專頁編號}?fields=access_token&access_token={剛剛取得的長效_User_Token} 點擊提交，返回的 JSON 數據中，access_token 欄位的值就是你最終需要的 長期粉絲專頁發文金鑰！ 將這個 Token 與你的 Page ID 填回 n8n 的 Data tables 中，前置作業就大功告成了。 如果你想先驗證 Token 是否真的可用，建議在 n8n 正式執行前，先用 Graph API Explorer 或 HTTP Request 測一次最小請求。只要能成功打到粉絲專頁資料，後續發文流程通常就不會差太遠。 補充：Facebook Page ID 怎麼找最快？如果你手上還沒有 Page ID，最穩的方式不是直接猜名稱，而是透過 Meta 工具或 Graph API 查詢實際 ID。因為在 n8n 串接 Facebook 發文時，真正用來指定目標粉專的是 Page ID，不是粉專顯示名稱。 你可以把這個觀念記住： 粉專名稱是給人看的 Page ID 是給 API 用的 只要這裡填錯，後面就算 Token 正確，發文也可能失敗或打到錯的目標。 n8n Facebook 自動發文失敗怎麼排查？常見報錯修復整理如果你在執行 n8n 工作流時遇到錯誤，通常是以下兩個原因： 1. Graph API 版本過舊Meta API 更新頻繁，模板中預設的 API 版本可能是 v23.0。若報錯，請進入 n8n 的 HTTP Request 節點（負責發布貼文的節點），將 URL 中的版本號手動更改為最新版，例如 v25.0： 1https://graph.facebook.com/v25.0/{{ $json.facebook_id }}/feed 2. If 節點 (判斷圖片是否存在) 報錯舊版的 n8n If 節點在讀取空值時容易發生中斷錯誤。若你的流程在判斷「是否上傳圖片」時卡住，建議將該原有的 If 節點刪除，重新拖曳一個新的 If 節點，並重新設定判斷條件（如判斷 binary.data 是否存在），即可解決錯亂問題。 3. 發文成功回傳 200，但粉專上看不到貼文這種情況通常不是 n8n 沒有送出，而是你打到的目標不是預期中的粉絲專頁、權限對錯頁、或貼文被發到不同類型的內容區塊。建議依序檢查： Data table 裡的 Facebook Page ID 是否填成正確粉專，而不是個人帳號 ID。 Access Token 是否真的是該粉專對應的 Page Token。 HTTP Request 節點送出的 endpoint 是否為 /{page_id}/feed，而不是其他物件路徑。 粉專角色是否足夠，且授權帳號仍然是該粉專的管理者或具備可發文權限的人員。 4. 明明有 Token，卻跳出權限不足或 OAuth 相關錯誤這通常代表問題不在「有沒有 Token」，而在於 Token 綁定的權限範圍不夠。最常見的修法是重新生成權杖，並重新勾選 pages_manage_posts、pages_read_engagement 等必要權限，再重新做一次長效與 Page Token 轉換。只換節點設定、不重拿權杖，很多時候是修不好的。 實務建議：讓 Facebook 自動發文流程更穩定的 4 個做法如果你是要把這個流程真的用在營運，而不只是測試一次，建議多做以下幾件事： 把 Token 到期日記錄下來長期 Token 不是永久有效。建議在 Notion、行事曆或任務系統中記錄建立日期與預估到期時間，避免某天排程突然中斷才回頭找原因。 先做最小發文測試一開始不要直接串完整的 AI 文案、自動抓圖、自動排程。先測最簡單的純文字貼文，確認 Page ID、Token 與 endpoint 都正確，再逐步加功能。 把錯誤訊息完整保留n8n 的執行紀錄、HTTP status code、Meta 回傳的錯誤訊息都很重要。很多 Facebook API 問題不是節點壞掉，而是錯誤訊息裡早就明講是版本、權限或參數不符。 避免把憑證硬寫在節點裡如果你未來還要串接 Instagram、Threads 或其他平台，建議持續用 Data tables 或統一憑證管理方式來控管金鑰，後續維護會簡單很多。 如果你接下來要改成 Facebook 多圖貼文這篇文章處理的是「先把 Facebook 自動發文打通」，也就是 Page ID、長期 Token、基本發文與常見權限問題。如果你已經能穩定發單圖或純文字，下一步通常就是改成多圖貼文。 但這一步不是只把欄位多複製幾份而已。Facebook 多圖貼文的正確做法，會需要： 表單支援多檔上傳 每張圖各自呼叫 POST /photos 收集所有 photo id 最後用 attached_media 一次組回 POST /feed 完整做法我另外拆成一篇：使用 Facebook Graph API 自動發布多圖貼文。如果你現在已經跑通這篇的單圖流程，建議直接接著看下一篇。 n8n 串接 Facebook 自動發文 FAQ以下這一段我特別整理成「真的會遇到的卡點」，如果你不是要理解原理，而是要把流程跑起來，這些問題通常最值得先看。 Q：為什麼我的 Facebook 發文權限一小時就失效了？A：因為你一開始拿到的通常不是最終可用的 Page Token，而是「短效期用戶權杖 (Short-lived User Token)」。這種 Token 常常只有約 1 小時效期，適合測試，不適合正式排程。 正確流程應該是： 先取得短期 User Token 再延長成長期 User Token 最後透過 API 轉換成對應粉專的 Page Token 只有完成第三步，你放進 n8n 裡的憑證才比較適合長期自動發文。很多人以為「已經拿到 Token」就可以了，結果其實只是停在第一步。 Q：建立 Meta 應用程式時，強制要求填寫「隱私權政策網址」該如何解決？A：Meta 為了合規性，要求上線的 API 應用程式必須具備隱私權政策。若你沒有自己的官網，最簡單的做法就是先用 Privacy Policy Generator 產生一份可公開存取的頁面，再把該 URL 貼回 Meta 後台。 實務上要注意兩件事： 這個網址必須能從外部正常開啟，不能是內網或尚未發布的頁面。 就算你現在只是自己測試，Meta 仍然常要求基本資料填完整，否則某些功能或狀態切換會卡住。 Q：執行 n8n 流程時出現 Graph API 版本錯誤怎麼辦？A：Meta 會定期淘汰舊版的 Graph API，所以你拿到的工作流模板就算之前能跑，過一陣子也可能因為版本過期而失效。最直接的做法，就是打開 n8n 中負責發文的 HTTP Request 節點，把 URL 裡的版本號更新成目前支援的版本，例如 v25.0。 如果你更新版本後還是報錯，不要只看版本本身，也要同步檢查： endpoint 路徑有沒有寫錯 權限是否完整 請求方法是否為 POST 送出的欄位名稱是否符合該 endpoint 要求 Q：Page ID 要去哪裡找？可以直接用粉專名稱代替嗎？A：不建議用粉專名稱硬猜，最穩的方式還是直接拿 Facebook Page ID。你可以在 Meta 的工具或相關 API 查到 Page ID，之後固定填進 n8n 的 Data table。因為實際發文 endpoint 是依照 ID 指向目標粉專，不是依名稱辨識。 如果你填錯 Page ID，常見結果有兩種： 直接報錯，表示找不到對應資源 成功執行，但其實打到錯的粉專或錯的頁面物件 Q：我明明是粉專管理員，為什麼還是無法發文？A：因為「你是管理員」不一定等於「這次授權出來的 Token 具備正確發文權限」。Facebook API 的世界裡，是否能發文不是只看帳號身份，還要看這次產生 Token 時到底勾了哪些 scopes。 換句話說，常見問題不是角色不夠，而是： 你勾漏了 pages_manage_posts 你拿的是 User Token，不是 Page Token 你授權的是 A 粉專，但實際要發的是 B 粉專 Q：n8n 裡建議用 Credentials 還是 Data tables 管理 Token？A：如果你現在是跟著模板快速實作，而且這份工作流本身就是用 Data tables 設計，那直接沿用 Data tables 會最快，也比較符合這篇教學的流程。它的優點是你可以把多個平台的憑證集中管理，後續替換比較方便。 但如果你的團隊之後會把這套流程做得更正式、更模組化，也可以評估改成 n8n Credentials 或其他集中式密鑰管理方案。重點不在工具名稱，而在於你要避免把 Token 分散寫死在不同節點裡，否則未來更新憑證會很痛苦。 Q：可以用這種方式排程每天自動發文嗎？A：可以，這正是 n8n 很適合的場景之一。你可以在前面接 Schedule Trigger，固定每天、每週或特定時段執行，再把產生好的文案送到 Facebook 發文節點。 不過正式排程前，建議先確認三件事： Token 已經換成長期可用的 Page Token 貼文內容來源是穩定的，不會臨時產出空值 流程裡有做基本錯誤處理，避免發文失敗卻沒人知道 Q：Facebook 自動發文可以順便帶圖片嗎？A：可以，但比起純文字貼文，圖片流程通常更容易出錯，因為你還要額外確認圖片檔案來源、格式、欄位名稱，以及 n8n 裡對 binary 資料的處理是否正常。這也是為什麼很多人在模板裡會卡在 If 節點或圖片判斷邏輯。 建議的做法不是一開始就硬上圖片版，而是： 先測純文字貼文 再測單張圖片貼文 最後才整合 AI 文案、圖片生成與排程 這樣你比較容易知道問題到底出在 Facebook API、n8n 節點，還是圖片資料本身。 Q：為什麼 n8n 測試時能發，排程時卻失敗？A：這種情況非常常見，因為手動測試與排程執行的上下文不一定完全一樣。最常見的原因包括： 測試時用的是手動輸入資料，排程時來源欄位其實是空的 Token 到排程執行時已失效 前面某個節點在排程模式下沒有成功輸出資料，導致發文節點吃到空值 所以你不能只看「手動跑一次有成功」，還要回頭檢查排程當下的 input/output 與 execution log。 Q：如果未來 Access Token 過期了，要整套重做嗎？A：通常不用整套重做，但你至少要重新完成「拿新 Token」這一段，並把新的值更新回 n8n 使用的地方。只要 App、粉專、流程本身都還在，通常不需要整套模板重建。 比較務實的做法是： 把 Token 更新流程寫成你自己的內部 SOP 記錄 Page ID、App 名稱、授權帳號 每次更換 Token 後立刻做一次最小發文測試 這樣下次出問題時，你不會又從零開始排查。 Q：這套流程適合哪些人先導入？A：最適合的是有固定社群內容產出需求的人，例如個人品牌經營者、顧問、行銷團隊、接案工作者，或本來就已經在用 n8n 串內容工作流的人。尤其如果你已經有固定的文案來源，例如 AI 產文、Notion 選題、Google Sheets 排程表，Facebook 自動發文會很容易接進去。 反過來說，如果你現在連貼文策略、審稿流程、內容節奏都還沒建立好，那先把 API 串起來不一定會立刻帶來效益。自動化放大的前提，是你原本的內容流程已經有基本穩定度。

為什麼社群自動化不能只追求「全自動」？許多人一接觸 AI 與自動化，第一個念頭就是：「能不能讓 AI 寫完文之後，直接自動發到 Facebook、Instagram、X、Threads？」 答案是技術上可以，但商業上通常不值得冒這個風險。 社群內容不是單純的文字搬運，而是品牌對外發聲。只要 AI 生成的資訊有誤、語氣偏掉、格式跑版，或誤用了不合時宜的字詞，就可能造成客服壓力、品牌信任受損，甚至引發公關危機。對大多數企業、自媒體團隊與接案行銷人員來說，更穩健的做法不是「全自動」，而是 半自動化（Human-in-the-loop）。 半自動化的核心精神很簡單： AI 負責加速產出：先生成貼文草稿、平台文案、標籤與 CTA。 人類負責最後把關：檢查事實、語氣、素材與排程是否正確。 系統負責穩定執行：核准後再由 n8n 自動分發到指定平台。 這種流程的優勢在於，你把最耗時的「重複性工作」交給系統，卻把最關鍵的「品牌判斷」留在人手上。效率有提升，風險也不會失控。 一套真正可落地的社群工作流長什麼樣？如果你想建立的是可以每天穩定運作，而不是只示範一次的流程，建議把整體架構拆成四層： 內容生成層：用 OpenAI 或其他模型產出各平台草稿。 內容管理層：用 Notion 當內容資料庫，集中管理文案、素材、狀態與排程。 流程執行層：用 n8n 根據狀態與時間條件執行發布邏輯。 結果回寫層：將發布結果、錯誤訊息、發布時間與平台連結回寫到 Notion。 這樣的設計有一個很大的好處：當流程某一段需要調整時，你只要修改那一層，不需要整套重做。例如你今天先發 Facebook，未來要擴充 LinkedIn 或 Threads，也只要增加分流與對應 API 邏輯即可。 內容資料庫該放哪裡？為什麼我更推薦 Notion在人工審核階段，你需要一個所有人都看得懂、也方便協作的內容資料庫。常見做法有兩種：Google Sheets 與 Notion。 Google Sheets 的優點是簡單、直觀、容易大量編修；但如果你的需求不只是存資料，而是希望團隊成員能更舒服地檢查文案、管理狀態、切換檢視與長期維護，那麼 Notion 會更適合作為內容中台。 原因很實際： 版面更適合內容審稿：不只是表格，而是可以用資料庫、看板、日曆等方式檢視。 欄位可讀性更高：小編、主管、客戶比較容易理解目前每篇文章卡在哪個階段。 更像內容管理系統（CMS）：未來要擴充 SOP、素材區、發文規範、提示詞模板，也能都留在同一個工作空間。 如果你想做的是長期能交接、能維護、能多人使用的流程，Notion 通常比單純的試算表更穩。 建議建立的 Notion 欄位為了讓 n8n 能穩定讀取與判斷，至少準備以下欄位： 文章標題（Title）：內部辨識用，不一定會直接對外發布。 主文內容（Content）：長文或主敘述內容。 平台文案（Caption）：針對社群平台的短文案，可依平台拆欄位。 發布平台（Platform）：多選欄位，例如 FB、IG、X、Threads、LinkedIn。 審核狀態（Status）：例如 Draft、Reviewing、Ready、Published、Failed。 立即發布（Publish Now）：勾選後可讓 n8n 優先處理。 預約發布時間（Scheduled Time）：做排程發布時會用到。 素材連結（Asset URL）：圖片或影片 URL，特別是 IG 幾乎一定會用到。 發布結果（Post URL）：成功後回寫平台貼文網址。 錯誤紀錄（Error Log）：方便追蹤 API 錯誤與人工補救。 如果你預計經營多平台，建議一開始就把「平台文案」與「素材」拆開，不要把所有東西都塞在同一個欄位中，否則後期擴充會很痛苦。 狀態管理才是自動化成功的關鍵很多人以為自動化的核心在 API 串接，但實務上，真正決定流程穩不穩的，通常是 狀態管理設計得好不好。 建議在 Notion 中至少規劃以下 5 種狀態： Draft（草稿）：AI 剛產出，尚未人工確認。 Reviewing（審核中）：編輯、主管或客戶正在修改內容。 Ready（準備發布）：內容、素材、平台都已確認，可交由系統處理。 Published（已發布）：已成功送出到指定平台。 Failed（發布失敗）：流程有執行，但 API 回傳錯誤或資料不完整。 多了 Failed 這個狀態很重要，因為真實世界的流程不可能永遠一次成功。當貼文因為字數超限、素材格式錯誤、Token 過期或 API 配額不足而失敗時，你需要明確知道它不是還沒發，而是「發送失敗，等待處理」。 n8n 要怎麼知道你準備好了？當文章在 Notion 中被標記為 Ready 後，n8n 需要一個觸發機制來接手。常見有兩種方式： 做法 A：排程巡檢（Schedule Trigger）這是最適合新手上手的方法。你可以設定 n8n 每隔 1 到 5 分鐘讀取一次 Notion，找出符合條件的資料。 優點： 設定簡單 不需要額外開發前端按鈕 容易除錯與觀察流程 缺點： 不是即時發布 如果排程太密，會增加不必要的 API 呼叫 做法 B：Webhook 即時觸發當你希望按下按鈕就立刻發文，或要從其他系統觸發 n8n，就可以用 Webhook。 優點： 幾乎即時執行 比較適合做人工核准後立即送出 缺點： 權限與安全性要處理好 建置成本比排程高一些 實務建議： 先用排程把流程跑穩，再考慮升級成 Webhook。多數團隊真正卡住的不是「延遲 3 分鐘」，而是資料格式與狀態管理不夠嚴謹。 一條穩定的 n8n 發布流程，至少要包含哪些節點？當 n8n 開始執行後，建議的基本邏輯如下： Schedule Trigger / Webhook：啟動流程。 Notion 查詢節點：讀取資料庫中符合條件的貼文。 IF / Filter：確認狀態為 Ready，且已達預約時間。 資料清理 / 格式化：處理文案長度、日期格式、平台欄位與素材欄位。 Loop / Split In Batches：逐筆處理，避免多篇一起失敗難以追蹤。 平台分流：依據平台呼叫不同 API，例如 Meta Graph API、X API、LinkedIn API。 成功回寫 Notion：更新狀態為 Published，記錄發布時間與貼文連結。 失敗回寫 Notion：更新狀態為 Failed，寫入錯誤訊息，方便人工補救。 如果你再往前走一步，還可以加入： 重試機制：暫時性 API 錯誤時自動重送。 Slack / Email 通知：發布成功或失敗時提醒相關人員。 審核紀錄：寫回最後編輯者與核准時間，讓流程更可追溯。 真正會踩雷的，不是 API，而是內容格式很多新手第一次做社群自動化，最容易忽略的是：不同平台根本不是把同一段文字複製貼上就能發。 例如： X（Twitter）：字數限制嚴格，太長就直接失敗。 Instagram：通常需要搭配圖片或影片，純文字流程很容易卡住。 Facebook / LinkedIn：可接受較長文，但語氣與換行邏輯仍需要調整。 Threads：文案節奏與互動感通常要比部落格摘要更口語。 所以，部落格長文、電子報內容與社群貼文應該視為三種不同內容型態，而不是同一份文案的不同輸出位置。 比較好的做法在 AI 生成階段，就直接要求模型輸出： 部落格摘要版 Facebook / LinkedIn 版 X 短文版 Instagram Caption 版 Hashtags CTA 這樣做的好處是，你的資料庫會從一開始就長得像「可發布資料」，而不是一團等待人工重寫的草稿。自動化流程要穩，前面的資料結構就不能含糊。 給新手的落地建議：先做小，再做快如果你現在正準備開始做這套系統，建議先用最小可行版本（MVP）上線： 先只做 單一平台，例如先串 Facebook。 先只做 排程發布，不要一開始就追求即時按鈕。 先只處理 單張圖片 + 單段文案，避免一開始就挑戰輪播、影片或多素材邏輯。 先把 成功回寫與失敗紀錄 做好，再談擴充。 只要這四件事能穩定運作，你就已經打下很強的基礎。之後再加入更多平台、更多模板、更多審核流程，整體成本會低很多。 常見問答（FAQ）Q：我可以把整套流程做到全自動，完全不人工審核嗎？A：可以，但不建議作為日常商業流程的預設模式。AI 生成內容仍可能出現事實錯誤、語氣失準、錯別字、敏感用語或品牌不一致的問題。對企業與品牌來說，省下幾分鐘審稿時間，通常不值得拿品牌風險去交換。比較務實的做法是保留人工核准，只把重複性工作交給系統。 Q：我不會寫程式，也能做出這套 n8n + Notion 工作流嗎？A：可以。這套流程本質上屬於低程式碼（Low-code）範圍，大部分邏輯都能透過 n8n 節點與 Notion 資料庫完成。真正需要花時間的不是寫程式，而是把欄位、狀態、平台規則與錯誤處理想清楚。只要流程設計正確，新手也能先做出可用版本。 Q：為什麼我在 X 或 Instagram 發文時常常失敗？A：最常見原因不是 n8n 壞掉，而是資料不符合平台規則。X 常見問題是字數超限；Instagram 常見問題是缺少必要素材、圖片格式不符，或 API 權限未設定完整。建議把不同平台的文案與素材拆欄位管理，並在發送前加入資料檢查節點，先擋掉不合法資料。 Q：Google Sheets 跟 Notion，我到底該選哪一個？A：如果你只是想快速驗證概念、資料欄位也很單純，Google Sheets 會更快上手；但如果你希望流程能長期維護、多人審稿、清楚管理狀態與內容，Notion 會更適合。簡單說，Sheets 比較像暫時資料表，Notion 比較像內容中台。 Q：我應該先做排程發布，還是直接做 Webhook 即時發布？A：建議先做排程。因為新手最需要先驗證的是資料結構、狀態流程與平台發布是否穩定，而不是「有沒有即時」。等到排程模式穩定之後，再把同樣邏輯改成 Webhook 觸發，風險會低很多。 Q：如果同一篇內容要發到 Facebook、Instagram、X，需要共用同一份文案嗎？A：不建議。你可以共用同一個主題與核心訊息，但每個平台最好有自己的 Caption。不同平台的字數限制、閱讀節奏、Hashtag 使用方式與 CTA 風格都不同。若硬要共用同一段文案，失敗率與成效不佳的機率都會提高。 Q：預約發布該怎麼設計比較安全？A：最穩的做法是同時判斷兩個條件：Status = Ready 且 Scheduled Time <= 現在時間。此外，成功發送後要立刻把狀態改成 Published，避免下一次排程重複發文。若流程可能重跑，也可以額外加入「已發送平台 ID」或「發布鎖」欄位做保護。 Q：如果 API 發布失敗，應該怎麼補救？A：不要只讓流程報錯結束，最好把錯誤寫回 Notion。建議至少回寫 Failed 狀態、錯誤訊息、失敗時間，必要時再發 Slack 或 Email 通知。這樣團隊成員能快速知道是哪一篇、哪個平台失敗，以及該補哪一段資料。 Q：這套流程適合哪些人先導入？A：最適合的是有固定內容產出節奏的人或團隊，例如自媒體經營者、內容行銷團隊、接案代操、顧問型品牌、課程講師與中小企業。只要你每週都在重複做「整理文案、人工貼上、切平台、確認格式」這些事，就很適合先從半自動化開始。