整合的記錄
保留客戶背景資訊
n8n 工作流程與您團隊已在 Workspace369 中管理的客戶、請求、專案、發票、付款、檔案和活動保持連結。
Workspace369 n8n 整合
Workspace369 的 n8n 整合現已可用，可在 n8n Cloud 或您自己的伺服器上運行。已付款發票、已接受報價或新潛在客戶透過 Webhook 節點啟動工作流程，HTTP Request 節點透過 Workspace369 API 建立或讀取客戶、發票、任務和專案。
工作流程執行
invoice.paid
POST your-n8n.example/webhook/… → 200HTTP Request
GET mcp.workspace369.com/v1/invoices/{id} → 200HTTP Request
POST mcp.workspace369.com/v1/tasks → 200Workspace369 事件進入，API 呼叫出去
營運契合度
支援正在進行的工作
將整合與銷售、排程、交付、通訊、帳單、報告和會計搭配使用，而不是將其視為獨立的工具。
團隊可見性
讓每個角色都看到相同的畫面
協助所有者、營運者、財務、支援和交付團隊了解發生了什麼事，而無需拼湊來自不同系統的記錄。
運作方式
n8n 如何與 Workspace369 協作
- 01
Workspace369 傳送觸發條件
在「設定」→「Webhooks」中，您將事件指向 n8n Webhook 節點的生產環境 URL。每個事件都會以簽署的 JSON 格式傳送，並包含記錄的 ID。
- 02
n8n 執行您的工作流程
節點使用事件的欄位，或 HTTP Request 節點先從 Workspace369 API 擷取完整的發票、提案或客戶。
- 03
HTTP Request 節點呼叫 API
HTTP Request 節點會透過純 HTTPS 和儲存為 n8n credential 的個人存取權杖呼叫 Workspace369 API。
觸發條件
可啟動工作流程的 21 個事件
發票
invoice.created, invoice.paid (已移至 Paid) 和 invoice.status_changed。
提案
proposal.sent, proposal.accepted 和 proposal.declined。
合約
contract.sent, contract.recipient_completed, contract.completed, contract.declined, contract.voided 和 contract.expired。
潛在客戶
lead.created、lead.converted 和 lead.archived，用於處理傳入的請求。
時間
time_entry.created、time_entry.updated、time_entry.deleted、timesheet.submitted、timesheet.approved 和 timesheet.rejected。
動作
Workspace369 中的工作流程可以做什麼
客戶
搜尋、讀取、建立和更新：GET 或 POST /v1/clients，GET 或 PATCH /v1/clients/{id}。
專案與任務
POST /v1/projects 和 POST /v1/tasks 會建立它們；PATCH 會更新它們。
提案、發票和合約
使用 POST /v1/proposals、/v1/invoices 或 /v1/contracts 建立草稿。傳送呼叫會等待人員在應用程式中核准，除非權杖擁有者開啟了「傳送前不詢問」選項。
日曆與請求
POST /v1/calendar/events 可預訂事件；PATCH /v1/requests/{id} 可更新請求的狀態。
任何其他工具
POST /v1/tools/{name} 會以名稱執行 OpenAPI 規格中的任何工具，例如 payments_record 或 time_entries_create。
原生節點
開發中。在此之前，請使用 Webhook 和 HTTP Request 節點進行連線。
設定
設定 n8n
- 01
新增 n8n 中的 Webhook 節點
使用 Webhook 節點啟動工作流程，將方法設為 POST，並複製生產環境 URL。如果將檢查簽章，請啟用 Raw Body 選項。
- 02
新增 Workspace369 中的 webhook
在「設定」→「Webhooks」中選擇「新增 webhook」，將 n8n 的生產環境 URL 貼為端點，選取事件並儲存。複製簽章金鑰；它只會顯示一次。發佈工作流程，使生產環境 URL 生效。
- 03
建立個人存取權杖
在「設定」→「AI 連線」中，建立一個僅具有該工作流程所需範圍的權杖，並將其儲存為 n8n 中的標頭認證。管理員必須已為工作區開啟 AI 連線。
- 04
從 HTTP Request 節點呼叫 API
新增 HTTP Request 節點。設定方法和 URL（例如 https://mcp.workspace369.com/v1/tasks），傳送 Authorization: Bearer 和您的權杖，以及包含欄位的 JSON 內文。
營運契合度
只有當團隊能夠看到內容時，連結才有用。
Workspace369 將整合保留在客戶記錄附近，因此業主、營運者、財務、支援和交付人員無需在獨立工具中重建相同的故事。
連接系統
在不改變團隊命名客戶、工作、發票和專案方式的情況下，將外部工作流程帶到 Workspace369 記錄旁邊。
保持背景資訊可見
顯示團隊已在工作的相關狀態、事件、付款、訊息或記錄。
從工作區採取行動
使用已連結的背景來進行後續處理、開票、排程、自動化、報告，並讓客戶持續推進。
實際上
團隊使用 n8n 的用途
在您自己的伺服器上執行自動化
自行託管的 n8n 會在您控制的伺服器上執行工作流程，而 Workspace369 會將事件傳送至該伺服器並從該伺服器接收 API 呼叫。
從其他系統建立 Workspace369 記錄
n8n 中的表單、資料庫或預訂工具可透過一個 HTTP Request 節點在 Workspace369 中建立客戶、專案、任務或日曆事件。
在採取行動前檢查每個事件
Code 節點可驗證每個事件的 HMAC-SHA256 簽章，因此工作流程僅針對 Workspace369 實際發出的請求運行。
常見問題
關於 n8n 的問題
- Workspace369 的 n8n 整合如何運作？
- 它使用 n8n 內建的 Webhook 和 HTTP Request 節點，可在 n8n Cloud 或自行託管中使用。Workspace369 的 Webhook 會將 21 個關於發票、提案、合約、潛在客戶和工時的事件發送到 Webhook 節點，而 HTTP Request 節點則透過 HTTPS 和個人存取權杖呼叫 Workspace369 Builder API。沒有關於客戶、專案、任務或預訂的事件；工作流程會透過 API 讀取這些資訊。如果其 Webhook URL 是標準埠上的公開 https:// 位址，則自行託管的 n8n 可以正常運作。
- 這裡的觸發條件和動作之間有什麼區別？
- 觸發條件來自 Workspace369：21 個 Webhook 事件中的一個會啟動工作流程。動作則反之：HTTP Request 節點透過 API 建立、更新或讀取客戶、專案、任務、發票、提案、合約和行事曆事件。傳送提案、合約或發票會返回 202，並等待人員在應用程式中核准，除非權杖擁有者啟用「傳送前不詢問」。
- 我需要哪個 Workspace369 方案？
- Specialist（每月 149 美元，10 個席位）及以上方案。Webhook 觸發條件和 Builder API 都需要 Specialist 方案。在 Cadet 和 Voyager 方案中，一旦管理員啟用 AI 連線，工作流程仍可透過 MCP 的 tools/call 呼叫相同工具，但無法接收 Webhook 觸發條件。
- n8n 工作流程會使用 AI 用量嗎？
- Zapier、Make 或 n8n 透過 API 或 MCP 執行的每個動作都會使用您工作區的一點 AI 用量；讀取比寫入和傳送使用的少。失敗的呼叫和 webhook 觸發器則不使用。
- 如何在 n8n 中檢查 webhook 簽章？
- 啟用 Webhook 節點的 Raw Body 選項並新增 Code 節點。它會計算原始主體後加上 X-Webhook-Timestamp 標頭的 hex HMAC-SHA256，並以您的完整 whsec_ 簽章金鑰進行比對，然後與 X-Webhook-Signature 進行比較。Webhook 節點不會為您檢查。
- n8n 有 Workspace369 節點嗎？
- 尚未。n8n 的原生節點正在開發中。在此之前，請依照本頁說明，使用內建的 Webhook 和 HTTP Request 節點進行連線。
繼續探索