昨天，我們已經透過 Graph API 測試工具取得了 Threads 的 access token，並成功的測試這個 token 是否可以使用。

然而，與 IG 和 FB 從 Graph API 測試工具取得的 token 一樣，這個 token 是屬於短期的測試 token。而且非常不幸的， Meta 並沒有在存取權杖測試工具裡面提供延長 threads token 的功能。今天，我們要把短期憑證延長為長期金鑰，確保它能長時間穩定運作；同時，在 n8n 中建立一條全新的工作流，包含 建立 Threads Container 與 正式 Publish Container 兩大步驟，讓你的訊息自動發佈到 Threads。

如果你還記得 Instagram 的「先裝箱再上架」流程，會發現 Threads 的發文邏輯和 IG 幾乎如出一轍。差別在於，Threads 無法使用 FB Graph API 的節點，必須使用 HTTP Request 節點去呼叫 Threads 專屬的 API，但其實觀念是非常類似的。

準備好了嗎？今天，就讓我們寫下第一則 自動化的 Threads 發文，正式解鎖三平台串接的最後一塊拼圖。

一、取得 Threads 長期金鑰

Step 1. 進入 Graph API 測試工具，並確認已取得短期Token。（可參考昨日文章內容）

Step 2. 透過 access_token 端點取得長期權杖

• 取得應用程式 ID 與密鑰：

  • 進入 Threads Meta Developer APP → 左下角應用程式設定 → 基本資料
  • client_id：應用程式編號
  • client_secret：應用程式密鑰
    

• 在 Graph API 測試工具上方的網址輸入：access_token?grant_type=th_exchange_token&client_id={threads 應用程式ID}&client_secret={Threads 應用程式密鑰}&fb_exchange_token={Graph API 右上角的臨時 Token}

client_id、client_secret、fb_exchange_token 替換為自己的，不用有中括號 { }，直接貼值

• 點選「提交」 → 畫面中的 access_token 即為 Threads 的長期 Token

  • 回傳會包含 access_token （長期 token）和 expires_in（秒數，換算大約 60 天）。
    

• 可將此串 Token 貼到存取權杖偵錯工具測試，可發現過期時間約為 60 天後
  

Step 3. 保存至 n8n

• 可將此串長期 Token 存在 n8n 的 Credentials 之中，一樣使用 bearer Auth type Credential（建議命名好，之後選擇的時候比較方便）

取得 token 後要存到 credential 中的步驟與 supabase 的非常相似，幾乎說是一模一樣

二、建立 Threads 發文工作流

以下為本次發文的完整工作流示意圖：

透過 Threads API 發文的步驟與 IG 類似，需要先建立 Container 再 publish container，無法像粉專一樣直接上傳圖片的檔案。

Step 0. 取得圖片URL、文案

• 與 Day 12 文章中 IG 發文的步驟類似，可透過 Google Drive、Supabase HTTP request 節點、Gemini 分析圖片節點、Merge 節點來取得圖片URL、文案內容

Step 1. 建立 Threads Container (HTTP Request 節點)

• 在 Merge 節點後方，新增一個 HTTP Request 節點
  

• Method：POST

• URL：https://graph.threads.net/v1.0/{threads_user_id}/threads

• Authentication：Predefined Credential Type → Bearer Auth → 選擇當初添加 Threads access token 的憑證

• Send Query Parameters：

  • Name : media_type ； Value：IMAGE
  • Name : text ； Value：文案內容（從 merge 節點拖曳文案文字）
  • Name : image_url ； Value：https://{supabase專案ID}.supabase.co/storage/v1{{ $json.signedURL }} （$json.signedURL是從 merge 節點中將 supabase 取得URL節點輸出的那段網址）

• 送出後會回傳一個 container_id。
  

Step 2. Publish Container （HTTP request 節點）

• 在建立 container 的節點後方加一個 HTTP Request 節點
• Method：POST
• URL：https://graph.threads.net/v1.0/{threads_user_id}/threads_publish

比較：建立 container 是用 threads 端點；推送 container 是用 threads_publish 端點，設錯的話節點會執行失敗！

• Authentication：Predefined Credential Type → Bearer Auth → 選擇當初添加 Threads access token 的憑證

• Send Query Parameters：

  • Name : creation_id ； Value：{{ $json.id }} （從前一個節點拖曳）

• 送出後會回傳一個 id ，這個 id 就是貼文的 id
  

• 執行後，你就會在 Threads 上看到新發出的貼文！
  

Step 3. 歸檔

• 與 Day 12 文章中 IG 發文的步驟相同，可透過 Google Drive Move File 節點、Supabase HTTP request 刪除檔案節點，將已經發文的照片進行歸檔、刪除

如果不擔心 supabase bucket 容量爆掉的話，也可以留著，自由心證。

三、結語與明日預告

到這裡，我們已經成功透過 n8n 在 Threads 上發文了！只要再把工作流加上 Schedule Trigger，就能讓發文自動化持續運作。

關於流程，你可能會注意到 Threads 和 IG 有些相似，也有不同：

• 相同點：都需要先建立 Container → 再 Publish。
• 不同點：IG 可以直接使用 n8n 內建的 FB 節點；Threads 則必須透過 HTTP Request 手動呼叫專屬 API。

但是其實 IG、FB 的發文也可以用 HTTP request 節點來實現，不一定要用 FB Grpah API 節點。你知道要怎麼設計嗎？可以想想看，後續有時間的話會提到!

如果你實際照著步驟操作，會發現三個 Meta 平台的發文流程其實有很多共通之處：從取得 access token 到設定發文節點，概念、流程很相似，可以稍微多思考一下各個節點參數的意義，理解背後邏輯後，換成其他操作也能很快上手。

掌握了這些概念並實作三大平台發文的工作流後，或許有一個更大膽的想法在你腦海中浮現：「是不是可以一次同時發文到 FB、IG 和 Threads 呢？」相信聰明的你，腦中已經浮現出將這些工作流整合起來的宏偉藍圖了。沒錯，這正是我們明天的任務！

明天，王者即將集結！我們會整合這幾天所學，打造一個一次輸入、三平台上稿的終極自動化神器。
Meta 三件套，正式合體，就在明天！