跨平台自動化、n8n、Webhook
想像企業日常流程橫跨多個平台：ERP 系統 Odoo 用於處理核心業務資料，同時團隊透過 LINE、電子郵件等渠道與客戶溝通。此外，公司網站設有聯絡表單供客戶留言。
在傳統方式下，這些系統之間往往缺乏自動連結，需要人工在各平台間來回切換與傳遞資訊，既耗時又容易出錯。
例如以下場景：
上述每個場景都涉及跨平台的資料流轉與自動化需求。如果能將 Odoo 這個核心系統與通訊平台和 AI 服務串連起來，我們就能打造出一個智慧自動化生態：讓 ERP 內的事件即時觸發，透過 n8n 平台串接 AI 分析與多通道通知，免除人工中介。本文將介紹如何運用 n8n 雲服務與 FastAPI Webhook 技術，深度整合 Odoo 18 on-premise 與 GPT-5 等 AI 服務，實現上述跨平台自動化流程。
接下來，我們會先說明整體架構，接著針對三種典型應用情境逐一拆解技術流程，並提供具體的設計思路與實作範例，包括 n8n 範例工作流程、節點設計原則，以及 Webhook 的安全設計。最後，我們也將討論流程的安全性、錯誤處理與部署最佳實踐，確保這套自動化生態系統既高效又可靠。
要實現上述跨平台自動化，我們需要串連數個核心組件：Odoo 18 ERP、n8n 自動化工作流程（Odoo 和 n8n 都有 SaaS 雲服務和本地部署的選項）、FastAPI Webhook 服務，以及大型語言模型 AI 引擎（GPT-5）。整體架構如下圖所示，各模組協同作用，讓企業事件從內部觸發，經過 AI 分析再流轉到外部平台完成通知或交互：
如上圖所示，Odoo 是企業資料的中樞，而 n8n 工作流程引擎則充當跨系統的「流程管控者」。當 Odoo 中發生特定事件（例如記錄狀態變更、新表單提交等）時，它會透過 Webhook 呼叫預先設定的 n8n 工作流程 URL，將相關資料發送出去。隨後，n8n 依照我們設計的流程邏輯執行一系列動作，包括：
透過以上架構，企業內部的關鍵事件都能即時觸發智慧反應，完全自動地完成跨系統的資料傳遞與任務執行。接下來，我們將以三個具體應用範例，說明這套架構在實務中的運行細節。
💡 Gary’s Pro Tip｜跨系統整合解耦與彈性
在設計跨平台工作流時，建議將各部分職責明確劃分：Odoo 專注提供觸發事件與資料，FastAPI 專注AI 邏輯處理，n8n 負責流程編排與條件控制。如此一來，各模組的耦合度降至最低，方便日後維護。例如要更換 AI 模型服務，只需修改 FastAPI 的實作；若新增另一個通訊渠道，也可在 n8n 中添加節點而無須改動 Odoo 或 AI 邏輯。這種結構讓整體系統更具彈性，任何一環升級不會影響其他部分。
下面我們針對先前提到的三種情境，深入剖析每個自動化流程的實現方式。每個範例都對應一條 n8n 工作流程，涵蓋從 Odoo 事件觸發、AI 處理到跨平台通知的完整路徑。
情境：在法律事務所中，合約審查完畢往往需要第一時間知會相關律師。傳統方式下，法務專員可能會發 LINE 訊息告知負責律師，並手動整理重點摘要提供參考。現在，我們希望當 Odoo 中一份合約記錄被標記為「審查完成」時，系統自動將該合約的重點摘要內容透過 LINE 發送給律師，實現即時通知與智慧摘要。
👨🏻💻 技術流程：
Odoo 事件觸發：我們在 Odoo 中對合約模型（例如 legal.contract）設置自動動作，監聽狀態字段的變更。如果某筆合約的狀態被更新為「已審查」，則透過 Webhook 呼叫 n8n 預先配置的 URL（例如：https://n8n.cloud/webhook/contract_review?token=XYZ）。Webhook 請求的內容可以包含合約的唯一 ID 及基本資訊（如合約標題）。這裡我們附加一個預共享的 token=XYZ 作為參數，用於在 n8n 流程中驗證請求來源，以防止未經授權的調用。
n8n 處理與 AI 摘要：n8n 的 Webhook Trigger 節點收到來自 Odoo 的 POST 後，會提取合約 ID 等資訊。我們隨即使用 Odoo 節點（或 HTTP 請求）調用 Odoo API，抓取該合約的完整內容欄位（例如合約條款文本）。接著，n8n 將合約文本傳遞給 FastAPI 的 /summarize_contract API。FastAPI 隨即調用 GPT-5，生成這份合約的摘要。在 Prompt 設計上，我們會請 GPT 抓出合約中的關鍵條款、時限及需律師注意的事項，並將答案以精簡段落形式返回。
LINE 通知發送：取得摘要後，n8n 使用 HTTP 請求節點 呼叫 LINE Messaging API 將訊息發送給目標律師。LINE API 需要我們提供 Channel Access Token 作為驗證，並指定接收者的 User ID 以及訊息內容。在 n8n 中，我們會把 LINE Token 設置為環境機密變數或 n8n 的 Credentials（憑證）來管理，避免直接硬編碼在流程裡。發送的訊息內容則包含合約標題和 AI 產生的重點摘要。例如：
🔔 合約《{XXX}》已審查完成
📄 摘要重點：{合約摘要 YYYY...}
律師在 LINE 上即可即時收到這則通知與摘要，大幅節省閱讀整份合約的時間。如果需要查看全文，通知中也可以附上相關系統文件連結。
結果回寫與紀錄：為了備查，我們能將摘要結果寫回 Odoo 合約記錄的備註欄位，或在合約的追蹤討論串中新增一則郵件，內容為「🤖 AI 摘要已發送給律師：{摘要內容}」。這樣未來可以在 Odoo 中檢視歷史紀錄，瞭解AI提供過哪些意見。
情境：企業網站上的「聯絡我們」表單常收到各式各樣的訊息，例如詢問服務內容、投訴、合作提案或求職資訊。這些表單提交後通常會進入 Odoo 的線索（Lead）或客服模組。我們希望對每則新留言自動判斷其類型與優先級，並讓 AI 幫忙決策是否需要人工跟進，或可以自動回覆/結案。
👨🏻💻 技術流程：
Odoo 表單事件：客戶提交網站表單後，Odoo 會產生一筆對應的線索紀錄，包含客戶提供的姓名、聯絡方式和留言內容。我們可設定 Odoo 在創建新線索時觸發一個 Webhook 到 n8n。同樣地，帶上一個安全 token 以供驗證。Webhook 請求中可直接附帶留言的文字內容和基礎分類（如果表單有分類欄位）。
n8n AI 分類判斷：n8n 工作流接收新留言資料後，首先可以執行初步關鍵字分類（例如偵測是否包含投訴字眼、銷售詢問等），這可利用 n8n 的函式節點或正則條件節點來實現。隨後，我們發送一個請求給 FastAPI 的 /classify_lead 接口，將留言全文傳給 GPT-5，讓 AI 從語意角度進行判斷。我們會提示 GPT-5：分析此留言的意圖，分類為「一般詢問」「投訴抱怨」「商業合作」「求職」等類別，並判定是否需要人工跟進。例如，GPT 可能回傳結果：{"category": "投訴", "escalate": true, "reason": "客戶表達強烈不滿，涉及重要服務故障"}。在這裡我們讓 AI 說明理由，方便日後追蹤改善。
💡 Gary’s Pro Tip｜語言模型在不同任務下的選擇
由於目前商業化的模型，都有收費便宜到昂貴的選項（依據模型的大小，也就是能力），所以如果要使用 LLM 模型來處理較為簡單的任務，例如說分類問題，就可以選擇小一點但是便宜的模型，如果是比較難的任務如總結、分析，再使用較大較昂貴的模型。
條件與處理：n8n 根據 AI 回傳的 category 及 escalate 字段進行條件分支：
escalate 為 true（需要人工處理），則透過 Odoo API 將該線索指派給相應負責人（例如分類是「投訴」就指派給客服經理，是「合作提案」就指派給業務經理）。這可使用 n8n 的 Odoo 節點執行更新操作，填寫記錄的負責業務員欄位等。同時，n8n 可透過 Email 節點 給負責人發送一封提醒郵件，內容包含客戶留言摘要和 AI 判斷結果（如：「系統自動判定此訊息為投訴類型，已標記需您跟進處理」）。escalate 為 false（無需人工跟進），我們可以自動發出預先定義的回覆給客戶。例如若分類為「一般詢問」，可以請 AI 根據常見問答庫生成一封初步答覆郵件給客戶，內容禮貌地回答問題或提供相關資訊。這封郵件可由 n8n 的 Email 節點發送，從而在無人工介入下完成閉環。同時將線索狀態標記為已回覆/已關閉，以免進入人工待辦。記錄與學習：無論哪種分支，我們都將 AI 的分類結果記錄在 Odoo 中，例如新增「AI 分類」字段填入類別，以及「AI 判定結果」字段註明是否需要人工處理與理由。日後管理者可統計這些資料，評估自動分類的準確率與收益。如有誤判案例，也能據此調整 AI 提示詞或分類規則，逐步優化系統。
💡 Gary’s Pro Tip｜建立一個可持續優化模型的流程
當系統上線後，並不是一個結束，而是挑戰真正的開始。而一個好的軟體服務系統，其中 AI 模型的準確度與滿意度，就是需要持續監控、修正、改善的一個重要面向。收集下來這些 AI 的回答，適時地做一些錯誤分析、資料分析，可以提供給優化 AI 部分的重要方向。
情境：在客服或技術支援場景中，新工單（工單可理解為客戶支援請求）建立後，若能立即給客戶一個初步的解決建議，將大大提升客服響應速度與客戶滿意度。假設客戶提交了一張關於產品故障的工單，我們希望系統自動將描述交給 GPT-5 生成可能的解決步驟建議，並透過電子郵件立即回覆給客戶，同時抄送給相關的客服人員。
👨🏻💻 技術流程：
/suggest_solution 接口。FastAPI 會使用 GPT-5 針對問題給出三到五條具體的建議步驟。例如某 IT 支援工單的 AI 建議可能包括：「請嘗試重新啟動設備、檢查連線、更新驅動程式...」。我們也要求 GPT 解釋每個步驟的原因，以增加專業說服力。message_post 在該工單附上一則內部備註「🤖 AI 建議已提供給客戶：...」。如此一來，日後客服人員查看工單時，可看到 AI 提供過的建議內容，以及客戶是否採納（可根據客戶後續回覆或工單狀態變化來判斷）。以上三種情境展示了跨平台自動化的威力。接下來，我們選擇**範例一（合約審查通知）**來說明完整的 n8n 工作流程如何實作，包括各節點配置、關鍵程式碼以及環境參數管理。您也可以依此類推，構建其他情境的流程。為便於復用，我們在 n8n 中採用了模組化、參數化的設計，使 Workflow JSON 可移植至不同環境。
在 n8n 平台上，新建一個名為「Contract Review Summary」的工作流程，並添加以下關鍵節點：
Webhook Trigger 節點 – Contract Reviewed Webhook：設定方法為 POST，路徑為 contract_review。這會生成對應的 Webhook URL（含隨機識別碼），我們將該 URL 填入 Odoo 自動化動作中。為安全起見，在Webhook認證中，我們要求一個查驗用的 Token：例如在 Webhook 節點設定中啟用「認證」，要求傳入參數 token=XYZ，並在節點中驗證其值是否正確，不符則中止流程。這可防止外部惡意呼叫。當觸發時，此節點會輸出 Odoo 傳來的 JSON 資料。
HTTP Request 節點 – Fetch Contract Content：這一步通過 Odoo API 獲取合約詳細內容。我們使用 HTTP Request 節點調用 Odoo 的 JSON-RPC 介面（或 REST API，如果 Odoo 18 提供了對應模組）。在請求中附上 Odoo 認證資訊（使用 n8n Credential 安全存放，例如 API 金鑰或 Basic Auth）以及合約 ID 作為參數，取得合約的完整文本欄位。例如請求為：{"model": "legal.contract", "method": "read", "args": [[<合同ID>], ["content"]]}。成功時，節點輸出合約的內容字串。
HTTP Request 節點 – Call GPT-5 Summarize API：將上一步取得的內容發送給 FastAPI 的 /summarize_contract 接口。為保持流程簡潔，我們直接在此節點組裝 JSON，例如：{"title": "<合約名稱>", "content": "<合約全文>"}。FastAPI 端會對請求進行 AI 摘要處理，返回一個 JSON，其中包含 summary 字段。我們同樣將 OpenAI API Key 等機密配置在 FastAPI 應用的環境變數中，而非暴露在 n8n。這個節點的回傳值即為 GPT-5 產生的摘要文字。
💡 Gary’s Pro Tip｜使用獨立的 AI API server
n8n 其實已經有提供 AI Agent 的節點了，那麼為什麼還需要多此一舉來另外做一個 AI API 呢？這是因為考慮到耦合性以及擴充性的問題，假如是使用本地端部署的 AI 模型，通常會是在 GPU heavy 的 cluster 上面，由於 GPU 的成本昂貴，很常會動態的調整 cluster 上的機器資源，所以如果都放在一台上，對於比較大的服務量體，用起來的彈性會小很多。
Function 節點（可選） – Format Summary Message：使用一個 Javascript Function節點來整理要發送的訊息格式。我們會將合約標題和摘要組合並加上適當的 Emoji/標題。例如：
const title = $node["Fetch Contract Content"].json["title"];
const summary = $node["Call GPT-5 Summarize API"].json["summary"];
return {
json: {
"message": `🔔 合約《${title}》已審查完成\n📄 摘要：${summary}`
}
};
這樣後續節點可以直接使用組裝好的 message。當然，也可在下一步的 HTTP節點中用表達式插值來格式化，這裡用函式節點是為了在流程上更清晰分隔邏輯。
HTTP Request 節點 – Send LINE Message：最後，我們配置一個 HTTP POST 請求至 LINE Messaging API 的推播端點，例如 https://api.line.me/v2/bot/message/push。我們在 Headers 中加入 Authorization: Bearer <ChannelAccessToken>（從 n8n Credential 讀入），在 Body 中放入要推送的內容。LINE 推播 API 需要指定接收者的 userId（可從 Odoo 合約記錄裡預先存的律師 LINE ID 獲取）以及訊息物件。我們將上一節點產生的文字放入 LINE 文本訊息結構中：
{
"to": "<律師的LINE UserID>",
"messages": [{ "type": "text", "text": {{$node["Format Summary Message"].json["message"]}} }]
}
送出請求後，LINE 伺服器若返回狀態碼 200 表示推播成功。此時律師即會在手機上收到通知。
配置好以上節點後，我們將工作流程設定為啟用（Active）並進行測試。以下為該 n8n Workflow 的 JSON 範例結構（已省略部分系統生成的識別碼與無關細節），可參考並根據自身環境調整：
{
"name": "Contract Review Summary",
"nodes": [
{
"id": "1",
"name": "Contract Reviewed Webhook",
"type": "n8n-nodes-base.webhook",
"parameters": {
"path": "contract_review",
"methods": ["POST"],
"responseMode": "onReceived",
"options": {
"authentication": "none"
}
}
},
{
"id": "2",
"name": "Fetch Contract Content",
"type": "n8n-nodes-base.httpRequest",
"parameters": {
"url": "http://odoo-server:8069/jsonrpc",
"method": "POST",
"authentication": "genericCredential",
"options": { "bodyContentType": "json" },
"body": {
"json": {
"params": {
"model": "legal.contract",
"method": "read",
"args": [ [ "{{$json[\"id\"]}}" ], ["name", "content"] ]
}
}
}
},
"credentials": { "httpBasicAuth": "OdooAPICreds" }
},
{
"id": "3",
"name": "Call GPT-5 Summarize API",
"type": "n8n-nodes-base.httpRequest",
"parameters": {
"url": "http://ai-server:8000/summarize_contract",
"method": "POST",
"body": {
"title": "={{ $node[\"Fetch Contract Content\"].json[\"result\"][0][\"name\"] }}",
"content": "={{ $node[\"Fetch Contract Content\"].json[\"result\"][0][\"content\"] }}"
},
"options": { "bodyContentType": "json" }
}
},
{
"id": "4",
"name": "Send LINE Message",
"type": "n8n-nodes-base.httpRequest",
"parameters": {
"url": "https://api.line.me/v2/bot/message/push",
"method": "POST",
"headers": {
"Authorization": "=Bearer {{ $env.LINE_TOKEN }}"
},
"body": {
"to": "={{ $json[\"lawyer_line_user_id\"] || \"<DefaultUserID>\" }}",
"messages": [
{
"type": "text",
"text": "={{`🔔 合約《${$node[\"Fetch Contract Content\"].json[\"result\"][0][\"name\"]}》已審查完成\\n📄 摘要：${$node[\"Call GPT-5 Summarize API\"].json[\"summary\"]}`}}"
}
]
},
"options": { "bodyContentType": "json" }
},
"credentials": {}
}
],
"connections": {
"Contract Reviewed Webhook": {
"main": [ [ { "node": "Fetch Contract Content", "type": "main", "index": 0 } ] ]
},
"Fetch Contract Content": {
"main": [ [ { "node": "Call GPT-5 Summarize API", "type": "main", "index": 0 } ] ]
},
"Call GPT-5 Summarize API": {
"main": [ [ { "node": "Send LINE Message", "type": "main", "index": 0 } ] ]
}
}
}
上述 JSON 定義了 Workflow 的節點及連線關係。在這個流程中，節點按照 Webhook -> 取資料 -> AI 摘要 -> 發送通知 的順序串聯。值得注意的是：
{{$node["節點名稱"].json[...]}} 這類 Expression 語法實現。我們可以方便地引用前面節點輸出的值作為後續節點的輸入。Fetch Contract Content 節點使用了預先定義好的 OdooAPICreds（假設我們在 n8n 中建立了名為 OdooAPICreds 的 Basic Auth 憑證，內含 Odoo 用戶名與密碼/API Token）。而 LINE 的 Channel Token 我們示範中從 $env.LINE_TOKEN 環境變數讀取；在實際 n8n 執行時，可以在 Workflow 的設定中將該環境變數對應到 n8n 帳號的 Credentials 或直接在 n8n 管理介面上設置一組 LINE API 憑證（然後在節點中選擇使用）。切勿將敏感金鑰直接明寫在 Workflow 中。透過 n8n 安全儲存，可以確保 API 金鑰在資料庫中加密保存。💡 Gary’s Pro Tip｜活用 n8n 範本與模組化
n8n 提供了許多現成範本（Templates）和社群貢獻的工作流程可以參考。在設計自己的流程時，不妨先搜尋是否有類似案例。例如針對 表單到 Odoo 的整合，n8n 官網就提供了將 Web 表單資料匯入 Odoo CRM的模板，可節省大量時間。另外，嘗試將重複使用的步驟（如發送通知或調用 AI）包成子工作流也是不錯的主意。透過 Execute Workflow 節點，我們可以建立可重複呼叫的子流程，實現流程的模組化。
當我們將自動化流程推向生產環境時，必須確保系統穩健運作且不因自動化引入新的風險。本節討論如何加強整體流程的安全性、可靠性，以及部署時的建議事項。
req.query.token 是否匹配預期值，不符則立刻返回 401 拒絕服務。同時，確保 Odoo 發出的請求是走 HTTPS 加密通道，以防攔截。若使用 n8n Cloud，Webhook 預設即為 HTTPS。即使設計完善，現實中 API 呼叫失敗、網路波動或模型錯誤都是可能發生的。我們需要讓流程穩健且具備自我恢復能力：
透過以上措施，我們能打造一個可靠的自動化系統：即使外部服務偶爾出問題，流程仍能智能地等待、重試或切換方案，不致影響最終業務連貫性。
透過今天的介紹，我們將 Odoo ERP 的強大資料中樞與 n8n 無程式碼自動化平台，以及 GPT-5 智慧引擎緊密結合，打造出真正跨平台的智慧工作流。合約審查完成自動通知摘要、客戶留言智能分流、工單即時建議回覆這三個範例只是冰山一角，幾乎所有需要不同系統協作的流程都能套用相似理念實現自動化。這些升級為企業帶來了實質效益：
值得一提的是，這種 Odoo × n8n × AI 的架構極具擴展性。未來我們可以輕易地新增更多自動化場景，例如：案件審批結果自動公告、多語言翻譯流程、自動化報表生成等。一旦搭建好跨平台自動化生態，企業就多了一位不知疲倦的數位員工，24 小時待命處理各種任務。透過不斷優化這套系統，企業將邁向真正的智慧營運：減少人工錯誤與延誤，同時發揮數據與 AI 的威力，創造前所未有的效率和競爭優勢。
iThome鐵人賽
看影片追技術