Partner API

基于 klikit 构建。

在您现有的 POS 之上加一层 API。对接 klikit 商户的订单、菜单、库存与结算，从免费沙盒一路到生产密钥。

打开 Partner Portal 下载入门手册（PDF）

核心理念

保留您的 POS，接入所有渠道。

您的硬件、员工培训和柜台流程完全不变。Partner API 通过 REST、Webhook 和 MCP 将您的系统对接到 klikit 商户。

保持不变

您的 POS：硬件、员工培训和柜台流程，一切照旧。

外卖渠道

所有外卖平台的订单，直接进入您的系统。

菜单全渠道同步

读取菜单，推送售卖状态与可见性。

库存与后厨

Inventory（库存）与生产，与销售保持同步。

结算

Disbursement（结算）：处理应付给商户的款项。

AI 助手

提供 MCP 服务器，编程助手可自行查阅文档。

谁在基于 klikit 构建

POS、ERP 与会员平台

将您的产品对接 klikit 商户：订单、菜单、库存。

商户技术团队

基于您的 klikit 数据构建自有工具。

系统集成商与服务商

代表商户交付 klikit 对接项目。

AI 编程助手

编写对接代码时直接查阅文档。

现已支持

读取订单

查询整个商户下的订单列表与详情，可按品牌、门店、状态和日期筛选。

读取菜单

获取单个门店应用覆盖设置后的菜单，或整个商户的全部菜单。

推送售卖状态

将菜品标记为有货或售罄，支持单个或批量操作，可安全重试。

订阅事件

订单创建、状态变更或购物车变更时，实时推送 Webhook。

两种对接方式

选择适合您系统的方式。

POS 或后厨系统

订单从 klikit 流入您的 POS，状态更新（已接单、已出餐、已取餐）再回传。

聚合平台或线上商城

klikit 菜单展示在您的平台上，您可切换菜品的有货/售罄状态并隐藏门店。

两种方式均可接入实时 Webhook，最后都需完成上线检查清单。

流程说明

从登录到生产密钥。

第 1–3 步 · 沙盒 · 快速通道
01
登录
工作邮箱加一次性验证码，无需密码。
第 1–3 步 · 沙盒 · 快速通道
02
阅读
Getting Started 入门教程与 Integration Playbook。
第 1–3 步 · 沙盒 · 快速通道
03
申请
选择产品并签署合作伙伴条款，klikit 确认您对接的商户。
第 4–6 步 · 生产 · 团队审核
04
开发
沙盒密钥、在线调试台、Ask AI 以及您自己的编程助手。
第 4–6 步 · 生产 · 团队审核
05
审核
申请生产环境，klikit 团队审核商户与权限范围。
第 4–6 步 · 生产 · 团队审核
06
上线
生成生产密钥，密钥仅显示一次。

环境

沙盒与生产环境对比。

	沙盒	生产
用途	使用仿真数据进行开发与测试。	真实 klikit 商户的线上数据。
需提供	对接类型、产品、市场。	另需提供对接的商户、您的法律实体及使用场景。
审核	快速通道。	klikit 团队确认商户与权限范围。

每个凭证的权限范围仅限单个商户，生产密钥只显示一次，访问权限可随时撤销。

参考价格 · USD

价格随规模灵活调整。

沙盒：永久免费。

Starter

1–10 家门店

US$49/门店/月

仅 Webhook
订单与菜单事件
标准支持

Growth

11–50 家门店

US$39/门店/月

仅 Webhook
订单与菜单事件
优先支持

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 查找与查询最匹配的章节，返回 URL 和摘要。
get_page 以 Markdown 格式完整读取一个页面。
list_pages 列出所有页面及其 URL 和说明。

不使用 MCP

将同一令牌作为 Bearer 请求头发送，即可把所有页面作为一个文本文件获取；也可在任意页面 URL 后加上 .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.

开始使用

今天就在沙盒中开始。

用工作邮箱登录，阅读 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.