透過 Quire API 串接外部工具——以 n8n 為例

最後更新：2026年7月20日

Quire 提供一個開放式 API，讓你能以程式化方式讀取及更新 Quire 任務。應用程式目錄中有許多應用程式，都是直接透過 Quire API 串接建構而成。

如果現有的應用程式無法滿足你的需求，不妨自己打造一個自訂整合。本文將以 n8n 為自動化平台範例，帶你了解 Quire API 的使用方式；同樣的概念也適用於 Zapier 等其他低程式碼平台。

這條路正逐漸成為主流。Gartner 曾預估，到 2025 年將有 70% 的組織新開發應用程式會採用低程式碼或無程式碼技術，相較於 2020 年的不到 25%，成長相當顯著。而 n8n 正是這類別中最廣受採用的開源選項之一。

本教學使用的 Quire API 端點

實作步驟有哪些？

1. 在 Quire 建立應用程式以取得 API 憑證
2. 準備並執行 n8n 執行個體
3. 在 n8n 中以 OAuth2 進行驗證
4. 發送第一個 API 請求（讀取任務）
5. 透過 API 建立或修改任務（寫入）
6. 使用 sourceRef 儲存來源參照或自訂中繼資料

1. 在 Quire 建立應用程式

要存取 Quire API，你需要在 Quire 中註冊一個應用程式，取得 client ID 與 client secret，並為 OAuth2 設定重新導向 URI。

若想了解如何搭配 API 建立 Quire 應用程式的完整步驟，歡迎參考我們的部落格文章。

2. 準備 n8n

你可以免費自架 n8n 進行測試，詳情可參考這份官方文件。

啟動後，建立一個新的工作流程，接著加入節點來執行 API 請求並處理回應。

3. 以 OAuth2 進行驗證

Quire 使用 OAuth2 進行授權。當你建立憑證時，n8n 會協助你代為處理 token 交換。

• 在工作流程畫面中，新增一組憑證並選擇 OAuth2 選項。

• 填入來自 Quire 應用程式設定的 client ID、client secret、授權網址、token 網址與重新導向 URI。重新導向 URI 必須從 n8n 複製後貼到你的 Quire 應用程式設定中，才能確保 OAuth2 流程正常運作。在 n8n 中，你必須將「Authentication」欄位設為 Body，才能確保憑證以 Quire 所需的正確格式傳送。

• 點選 Connect to my account，n8n 會將你重新導向至 Quire 的授權頁面。選擇要授權的專案並完成流程。

4. 發送第一個 API 請求（讀取任務）

Quire API 文件：https://quire.io/dev/api/

使用 n8n 的 HTTP Request 節點呼叫 API。舉例來說，取得某個專案的所有根層級任務：

• 基本網址：https://quire.io/api
• 端點：/task/list/id/{projectId}（將 {projectId} 替換為你專案網址中的專案 ID，通常網址格式為 https://quire.io/w/<projectId>）

在 HTTP Request 節點中：

• 方法：GET
• 網址：https://quire.io/api/task/list/id/<your_project_id>
• Authentication：Generic Credential Type
• Generic Auth Type：OAuth2 API
• OAuth2 API：<你剛才建立的憑證>

執行該節點後，你會在右側面板看到回應資料，接著就能將這些資料傳遞給後續節點進行處理。

5. 建立或修改任務（寫入）

你可以透過 API 建立任務（請參閱文件中的新增任務）。

• 端點：/task/id/{projectId}

在 n8n 的 HTTP Request 節點中：

• 方法：POST
• 網址：https://quire.io/api/task/id/<your_project_id>
• 啟用 Send Body，並填入必填欄位（例如 name）及選填欄位（例如 description）。

啟用 Send Body 後，請務必將 Body Content Type 設為 JSON，並將 Specify Body 設為 Using JSON。這樣就能以 JSON 格式輸入請求內容，如下方範例程式碼所示：

{
  "name": "Example task",
  "description": "Created via n8n"
}

執行該節點後，回應中會包含新建立的任務詳情，你也會在 Quire 專案中看到這個任務。

6. 使用 sourceRef 儲存來源參照與自訂資料

包含 sourceRef 的請求內容範例：

{
  "name": "Task from n8n",
  "description": "Automated task",
  "sourceRef": {
    "text": "[Open in MyApp](https://example.com/item/123)",
    "meta": { "workflowId": "n8n-abc-123" }
  }
}

sourceRef 是專門用來儲存與任務相關之自訂資料的欄位。唯一預先定義的欄位是 text，它支援 Markdown，並會顯示在 Quire 任務詳情中，非常適合放連結或簡短說明讓使用者點選。至於你在 sourceRef 底下加入的其他欄位，則完全取決於你的應用程式需求；舉例來說，你可以加入 meta 物件或其他鍵值，用來儲存識別碼或旗標供你的自動化流程使用，不過這些都是選填的。

當你透過 API 讀取任務時，可以在回傳的 JSON 中找到 sourceRef 物件。你能取得其中的 text 欄位以及任何你儲存的自訂資料，讓你的自動化流程輕鬆追蹤來源，並在後續處理時攜帶額外資訊。

另一個在建立或更新任務時很實用的欄位是 asUser。

如果你將 asUser 設為 true，活動紀錄就會顯示 Quire 應用程式的名稱作為建立或更新該任務的使用者。這能幫助使用者辨識哪些任務是由 API 整合建立的。

如何處理 Quire API 錯誤？

四種 HTTP 狀態碼幾乎涵蓋了你在呼叫 Quire API 時會遇到的所有問題。每一種都有對應的解法：

• 401 Unauthorized：檢查你的 OAuth2 token 是否有效且尚未過期，並確認憑證設定正確無誤。
• 400 Bad Request：檢查你的請求內容與參數，確保 JSON 格式正確，且必填欄位齊全。
• 403 Forbidden：確認你的應用程式與使用者是否擁有存取該專案或資源的授權。
• 404 Not Found：仔細核對你所使用的 API 端點與專案／任務 ID。

務必參考 Quire API 文件，了解錯誤訊息與必填參數的詳細說明。若遇到錯誤，請仔細閱讀回應訊息，通常裡面會提示問題所在。

如何透過 Quire API 實作雙向同步？

如前述文章所提到的，你也可以使用 n8n 與 Quire API 自行打造雙向同步方案。

想看實際範例，歡迎參考我們的開源儲存庫：n8n Quire API。這個儲存庫提供逐步指南與可直接使用的範本，讓你更容易在自己的應用程式與 Quire 之間實作雙向同步。

若想了解如何透過 Quire API 建立雙向同步的完整步驟，歡迎參考我們的部落格文章。

下一步該怎麼做？

現在你已經掌握了讀取任務、建立任務、以 sourceRef 附加來源中繼資料，以及透過 asUser 在活動紀錄中標示整合來源等技巧。同樣的模式也能延伸應用到其他 Quire API 端點；官方 API 文件是最具權威性的參考資料。

如果遇到問題，上方的錯誤處理段落涵蓋了四種最常見的 HTTP 回應。若有其他疑問，歡迎來信至 feedback@quire.io。

相關文章：5 分鐘完成 Quire MCP 設定：連接 Claude、ChatGPT 或任何 AI 用戶端——如果你想讓 AI 用戶端直接與 Quire 互動，而不用自己撰寫 API 呼叫程式碼，MCP 會是更快的方式。

相關文章：逐步指南：設定 Quire Webhooks——Webhooks 能在 Quire 中發生變動的當下，立即將更新推送到你的自動化流程，不必讓工作流程持續輪詢 API。

常見問題

什麼是 Quire API？我可以用它做什麼？

這是一個開放式 API，可用來以程式化方式讀取及更新 Quire 任務。當應用程式目錄中現有的應用程式不符合需求時，可以用它來打造自訂整合。

如何驗證 Quire API？

Quire 使用 OAuth2。註冊一個 Quire 應用程式，取得 client ID 與 secret，並將 n8n 的 authentication 欄位設為 Body，才能以 Quire 所需的格式傳送憑證。

我可以用 n8n 串接 Quire 嗎？

可以。免費自架 n8n 或使用 n8n.cloud，接著透過 HTTP Request 節點搭配 OAuth2 憑證讀寫任務。同樣的模式也適用於 Zapier 等類似平台。

Quire API 中的 sourceRef 是什麼？

sourceRef 用於在任務上儲存自訂資料。預先定義的 text 欄位支援 Markdown，並會顯示於任務詳情中，你也可以附加其他鍵值，例如 meta，用來追蹤來源或攜帶自動化中繼資料。

當 Quire API 回傳錯誤時，我該檢查什麼？

401 代表 token 出了問題，400 代表請求內容有誤，403 代表授權問題，404 則代表端點或 ID 錯誤。仔細閱讀回應訊息，通常會直接指出解決方向。