Partner API

在 klikit 上開發。

在您現有的 POS 之上加一層 API。串接 klikit 商家的訂單、菜單、庫存與撥款，從免費沙盒一路到正式環境金鑰。

前往 Partner Portal 下載簡介（PDF）

核心概念

保留您的 POS，接上所有通路。

您的硬體、員工訓練與櫃台作業流程完全不變。Partner API 透過 REST、webhooks 與 MCP，將您的系統串接到 klikit 商家。

您保留的

您的 POS：硬體、員工訓練與櫃台作業流程，一切照舊。

外送通路

所有外送平台的訂單，直接進入您的系統。

菜單全通路同步

讀取菜單，推送供應狀態與顯示設定。

庫存與廚房

庫存與備料生產，與銷售同步。

撥款

透過 Disbursement（撥款）處理應付給商家的款項。

AI 代理

提供 MCP 伺服器，讓程式開發代理自行閱讀文件。

誰在 klikit 上開發

POS、ERP 與會員集點平台

將您的產品串接 klikit 商家：訂單、菜單、庫存。

商家技術團隊

以您的 klikit 資料為基礎，打造自己的工具。

系統整合商與代理商

代表商家完成 klikit 串接。

AI 程式開發代理

撰寫串接程式時，直接閱讀文件。

現在就能做到

讀取訂單

列出並查詢整個商家的訂單，可依品牌、門市、狀態與日期篩選。

讀取菜單

取得單一門市套用覆寫設定後的菜單，或整個商家的菜單。

推送供應狀態

將品項標示為有貨或售完，可單筆或批次處理，並可安全重試。

訂閱事件

訂單建立、狀態變更或購物車變更時，即時透過 webhooks 通知。

兩種串接方式

選擇適合您系統的方式。

POS 或廚房系統

訂單從 klikit 流入您的 POS，狀態更新（已接單、已備妥、已取餐）再回傳。

外送平台或線上市集

klikit 菜單出現在您的平台上，您可切換品項有貨或售完，並隱藏門市。

兩種方式都支援即時 webhooks，最後都以正式上線檢查清單收尾。

運作方式

從登入到取得正式環境金鑰。

步驟 1–3 · 沙盒 · 快速通道
01
登入
使用公司 email 與一次性驗證碼，無需密碼。
步驟 1–3 · 沙盒 · 快速通道
02
閱讀
Getting Started 入門課程與 Integration Playbook。
步驟 1–3 · 沙盒 · 快速通道
03
申請
選擇產品並簽署合作夥伴條款，由 klikit 確認您的商家。
步驟 4–6 · 正式環境 · 團隊審核
04
開發
沙盒金鑰、Playground、Ask AI，以及您自己的程式開發代理。
步驟 4–6 · 正式環境 · 團隊審核
05
審核
申請正式環境，由 klikit 團隊審核商家與權限範圍。
步驟 4–6 · 正式環境 · 團隊審核
06
正式上線
產生正式環境金鑰，金鑰只會顯示一次。

環境

沙盒與正式環境，並列比較。

	沙盒	正式環境
用途	以擬真資料開發與測試。	真實 klikit 商家的正式營運資料。
您需提供	串接類型、產品、市場。	另加您串接的商家、您的法人實體與使用情境。
審核	快速通道。	由 klikit 團隊確認商家與權限範圍。

每組憑證僅限單一商家使用，正式環境金鑰只顯示一次，且可隨時撤銷存取權。

參考價格 · USD

依用量彈性調整的價格。

沙盒：永久免費。

Starter

1–10 間門市

US$49/門市/月

僅限 webhooks
訂單與菜單事件
標準支援

Growth

11–50 間門市

US$39/門市/月

僅限 webhooks
訂單與菜單事件
優先支援

Scale

51–200 間門市

US$29/門市/月

+ 另收客製開發費

完整 Partner API
Inventory and Disbursement（庫存與撥款）
專屬串接負責人

Enterprise

200 間以上門市

客製化

+ 另收客製開發費

包含 Scale 所有功能
量大優惠價格
客製化 SLA

僅供參考。最終價格將於正式環境核准時，依啟用門市數與訂單量確認。

給 AI 程式開發代理

讓您的代理自己讀文件。

Partner Portal 提供 MCP 伺服器與純文字文件，讓 Claude Code、Cursor 等程式開發代理在撰寫串接程式時，能自行搜尋並閱讀串接指南。

1. 建立文件存取權杖

由您團隊中的一位成員登入 portal.klikit.io，為每個代理或每台機器建立個人權杖（kpt_…）。最多可同時擁有 10 組，撤銷其中一組不影響其他權杖。

2. 連接您的代理

使用您的權杖加入 MCP 伺服器。任何支援 Streamable HTTP 與自訂標頭的 MCP 用戶端皆可使用。

3. 您的代理能做什麼

三個唯讀工具，每組權杖每分鐘最多 120 次呼叫：

search_docs 找出最符合查詢的段落，附上網址與摘要片段。
get_page 以 Markdown 格式讀取完整頁面。
list_pages 列出所有頁面及其網址與說明。

不使用 MCP

將同一組權杖以 Bearer 標頭送出，即可將所有頁面取得為單一文字檔，或在任何頁面網址後加上 .md。/llms.txt 的頁面索引為公開。

文件權杖只能讀取文件，無法呼叫 Partner API。API 憑證來自您在入口網站中已核准的申請，應存放在您的機密管理工具中，切勿寫進程式碼或 git。

Claude Code

claude mcp add --transport http klikit-docs https://portal.klikit.io/mcp \
  --header "Authorization: Bearer kpt_…"

Cursor (~/.cursor/mcp.json)

{
  "mcpServers": {
    "klikit-docs": {
      "url": "https://portal.klikit.io/mcp",
      "headers": { "Authorization": "Bearer kpt_…" }
    }
  }
}

VS Code (.vscode/mcp.json)

{
  "servers": {
    "klikit-docs": {
      "type": "http",
      "url": "https://portal.klikit.io/mcp",
      "headers": { "Authorization": "Bearer kpt_…" }
    }
  }
}

給代理的說明

在您的程式開發代理開始工作前，將這段內容貼進它的上下文。

You are building an integration with klikit, a restaurant operating system used by merchants across Asia.

Docs: https://portal.klikit.io (MCP server at https://portal.klikit.io/mcp, page index at https://portal.klikit.io/llms.txt). Use search_docs / get_page before writing code; prefer the docs over assumptions.

What the klikit Partner API covers: reading orders and menus, pushing item availability (in/out of stock) and store visibility, and webhooks for order events. Inventory and Disbursement are separate products with their own docs.

How to work:
1. Read the Integration Playbook first. It is phased: foundation (credentials, environment, scopes), map the business (brands and branches), then ONE path: POS/kitchen system (orders in, status back) or aggregator/marketplace (menus out, availability and visibility in), then webhooks, then the production checklist.
2. Every credential is scoped to one business. Build and test against the sandbox (development) environment; production access requires an approved application.
3. Send an Idempotency-Key on every write. Verify webhook signatures before trusting a payload.
4. Never hard-code or commit credentials. Read them from environment variables or a secrets manager. A docs token (kpt_…) only reads the docs; it cannot call the Partner API.
5. When something in the docs is unclear, stop and ask the human rather than guessing at behaviour.

開始使用

今天就從沙盒開始。

使用公司 email 登入、閱讀 Playbook，並申請沙盒金鑰。完全免費，您的團隊或程式開發代理可以立即開始開發。

前往 Partner Portal 有問題嗎？請來信 integrations@klikit.io

沙盒

正式環境

用途

以擬真資料開發與測試。

真實 klikit 商家的正式營運資料。

您需提供

串接類型、產品、市場。

另加您串接的商家、您的法人實體與使用情境。

審核

快速通道。

由 klikit 團隊確認商家與權限範圍。

You are building an integration with klikit, a restaurant operating system used by merchants across Asia. Docs: https://portal.klikit.io (MCP server at https://portal.klikit.io/mcp, page index at https://portal.klikit.io/llms.txt). Use search_docs / get_page before writing code; prefer the docs over assumptions. What the klikit Partner API covers: reading orders and menus, pushing item availability (in/out of stock) and store visibility, and webhooks for order events. Inventory and Disbursement are separate products with their own docs. How to work: 1. Read the Integration Playbook first. It is phased: foundation (credentials, environment, scopes), map the business (brands and branches), then ONE path: POS/kitchen system (orders in, status back) or aggregator/marketplace (menus out, availability and visibility in), then webhooks, then the production checklist. 2. Every credential is scoped to one business. Build and test against the sandbox (development) environment; production access requires an approved application. 3. Send an Idempotency-Key on every write. Verify webhook signatures before trusting a payload. 4. Never hard-code or commit credentials. Read them from environment variables or a secrets manager. A docs token (kpt_…) only reads the docs; it cannot call the Partner API. 5. When something in the docs is unclear, stop and ask the human rather than guessing at behaviour.