当前接口状态 · 正常

卡密激活与封禁接口，快速管理

  • API文档
  • 错误码参照
  • 示例代码
  • 加密与签名

接口地址： https://yz.jilicun.com/api.php?api=activa

备用接口： https://yz1.jilicun.com/api.php?api=activa

海外接口： https://www.ban365.com/api.php?api=activa

返回格式： JSON

请求方式： GET/POST

请求示例： https://yz.jilicun.com/api.php?api=activa&app=10000 复制示例 跳转示例

请求参数说明：

名称 变量 必填 类型 说明
接口 api 是 GET 填写activa
应用 app 是 GET 填写后台应用APPID
卡密 kami 是 GET/POST 填写提交的卡密
状态管理 state 是 GET/POST 填写提交state=1为激活，state=2为封禁
数据签名 sign 否 GET/POST 如果开启了[数据签名]需提交此项

返回参数说明：

名称 类型 说明
code String 返回状态
kami String 提交的卡密
message String 卡密状态

返回示例：

{
    "code":200,
    "msg":{
        "kami":"cefUniU3n6",
        "message":"卡密已成功激活"
    },
    "time":1755883111,
    "check":"bc444b6b37246bd942ca1b356e1f147c"
}

错误码格式说明：

名称 类型 说明
101 String 应用不存在
102 String 应用已关闭
171 String 接口维护中
172 String 接口未添加或不存在
104 String 签名为空
105 String 数据过期
106 String 签名有误
148 String 卡密为空
149 String 卡密不存在
151 String 卡密禁用
169 String IP不一致
201 String 卡密已到期

代码示例：

暂未添加示例代码

一、数据加密（后台：应用安全配置 → 数据加密类型）

开启后，请求参数与返回数据都按该算法处理。加密模式下业务参数不再直接放在 URL 上，而是整体加密后作为 data 参数提交；api 与 app 仍放在 URL 上。

类型值算法需要的密钥（后台配置项）
0不加密（明文）无
1RC4（E4A 系列，GBK 编码）rc4_key
2BASE64无
3RC4-2（十六进制字符串）rc4_key
4AES-GCMrc4_key
5sig 修改器加密（BASE64）无
6AES-256-CBC（独立 IV）aes_key + aes_iv
7DES-ECBrc4_key（8 字节）
8DES-CBCrc4_key（8 字节）
93DES-ECBrc4_key（24 字节）
103DES-CBCrc4_key（24 字节）
11AES-256-CBCrc4_key
12AES-256-ECBrc4_key
13RSA 非对称加密rsa_public_key / rsa_private_key
14SM4（国密）rc4_key（16 字节）

二、加密模式下的提交方式（重点）

把业务参数按顺序拼成 k=v&k2=v2 的字符串，整体加密后做 Base64，作为 data 提交：

// 以 kmlogon 为例（字段名与顺序请以本页「示例代码」标签页为准）

// ① 先拼出「参与签名」的参数串
signStr = "kami=" + 卡密 + "&user=" + 用户账号 + "&markcode=" + 机器码 + "&t=" + 时间戳
//   实际形态：kami=AAAA-BBBB-CCCC-DDDD&user=&markcode=00000000000000000000000000000000&t=1789800447

// ② 算出 sign（算法见第三节），连同随机值 value 一起拼进载荷
sign    = MD5( signStr + "&" + APPKEY )
payload = signStr + "&sign=" + sign + "&value=" + 随机值
//   实际形态：kami=AAAA-BBBB-CCCC-DDDD&user=&markcode=00000000000000000000000000000000&t=1789800447&sign=6f1ed002ab5595859014ebf0951522d9&value=32768

// ③ 整体加密后做 URL 编码，作为 data 提交
data = URL编码( Base64( 用配置的算法加密( payload ) ) )
请求  = api.php?api=kmlogon&app=APPID&user=用户账号&data=data
//   实际形态：api.php?api=kmlogon&app=10001&user=&data=j8KdR2mQ9vT1...

重要 每个接口的载荷字段都不一样，上例只是 kmlogon 的形态；请以本页「示例代码」标签页中该接口的拼接方式为准。

注意 user 要同时作为 URL 参数提交（见上例第 ③ 步，官方示例代码也是这么写的）。因为 fen（积分卡）、vip（会员卡）这两类卡密是从 URL 参数读取用户账号的，只放进加密载荷会返回 110　请填写账号。其余业务参数只出现在载荷里即可。

说明 上例是把 sign 一起放进载荷再整体加密（即后台「签名放DATA里」开启，这也是官方示例代码的做法）。若该项关闭，则 sign 不拼进载荷，改为作为独立参数提交：api.php?api=kmlogon&app=你的应用ID&data=加密结果&sign=签名值。

注意点说明
data 必须 URL 编码 Base64 里的 + 在 URL 中会被解析成空格并被服务端安全过滤删除，导致解密失败（返回 107）。请把 + 转成 %2B、/ 转成 %2F、= 转成 %3D。
载荷的值不能含 = 和 & 服务端按 & 分段、按 = 拆键值且要求恰好切成两段，值里出现这两个字符会导致该字段被静默丢弃。
URL 上的业务参数会被忽略 加密模式下只认解密出来的载荷内容，URL 上再写 kami / markcode 无效。
键的书写顺序 载荷中键的顺序会影响签名结果，请在整个项目里保持稳定。

三、数据签名（后台：数据签名开关 / 签名放DATA里）

签名算法为 32 位小写 MD5，签名对象是加密前载荷中的业务参数串（即上例第 ① 步的 signStr，不含 sign 与 value 本身；注意不是 URL 上的参数）：

sign = MD5( signStr + "&" + APPKEY )
// signStr 即上例第 ① 步拼出的 "kami=...&user=...&markcode=...&t=..."
// APPKEY 是该应用的 appkey（注意：不是 rc4_key）
// 参与签名的只有 signStr 里的字段，sign 与 value 自身不参与

// 承接上例：
// MD5("kami=AAAA-BBBB-CCCC-DDDD&user=&markcode=00000000000000000000000000000000&t=1789800447"
//     + "&" + APPKEY)
配置客户端做法
签名放DATA里 = 关闭 把 sign 作为独立参数提交：api.php?api=xx&app=yy&data=zz&sign=计算值（GET / POST 均可）
签名放DATA里 = 开启 把 sign 放进载荷里再整体加密：kami=xx&markcode=yy&t=zz&sign=计算值；服务端计算签名时会自动剔除 sign 本身

要点 签名串只包含本次接口用到的键，多带任何参数都会导致 106；服务端比较时会统一转为小写，所以 sign 传大写也能通过。

易错 值为空的参数同样参与签名。例如上例中的 user= 虽然是空值，也会被拼进签名串；漏掉任何一个已提交的字段都会返回 106。

明文模式注意 当加密类型为「不加密」时，服务端参与签名的参数值经过了一层安全过滤，若参数里含 &、'、"、<、> 等字符，签名将对不上。建议加密模式 + 数据签名配合使用。

四、时间差效验

项目说明
校验规则必须提交 t，且 | 服务器时间 - t | ≤ 时间差效验值（双向校验，填未来时间同样会被拒绝）
填 0不校验，t 可以为空
重要因为 t 在密文内部，开启后每次请求都必须重新加密生成 data，不能缓存复用
建议取值60 ~ 300 秒，同时要求客户端设备时间准确

五、调试模式（排查签名专用）

开启后，服务端会把它自己计算签名的原始字符串（尚未 MD5）直接明文输出并中断请求，用于和客户端拼串逐字符比对：

// 开启调试模式后，发任意一次请求（即使不带 sign）
// 服务端直接返回签名原串（下方为示意，实际按本接口载荷字段拼接）：
kami=你的卡密&markcode=你的机器码&t=当前时间戳&你的APPKEY

注意 开启期间所有请求都会停在这一步，排查完请立即关闭。输出内容为明文，与加密设置无关。

六、RSA 非对称加密（加密类型 = 13）

方向做法
请求（客户端 → 服务端）客户端用 公钥 加密载荷 → 服务端用私钥解密
响应（服务端 → 客户端）服务端用 私钥 加密 → 客户端用 公钥 解密

密钥对在后台「应用安全配置」中一键生成，客户端只需内置 公钥。分块规则：明文每 117 字节为一段，每段独立加密后拼接，再整体 Base64；1024 位密钥下每段密文为 128 字节。

安全性说明 响应方向使用「私钥加密」在数学上属于签名而非加密 —— 任何持有公钥的人（即任何拿到客户端的人）都能解开响应，因此该方向只保证完整性与来源，不保证机密性；真正保密的只有请求方向。

七、接口独立配置的优先级

「卡密管理 → 接口列表 → 独立配置」中若开启了安全配置，则该接口的 加密类型 / 数据签名 / 签名放DATA里 / 时间差效验 / rc4_key 以接口级为准，会覆盖应用级设置；密钥类字段（aes_key、aes_iv、RSA 公私钥）与调试模式只有应用级，不受接口配置影响。排查加密异常时请先确认该接口的独立配置状态。

八、常见错误与排查

现象原因与处理
107　数据为空未提交 data，或 data 解密失败。检查 data 是否做了 URL 编码、载荷格式是否为 k=v&k2=v2
104　签名为空开启了数据签名但没带 sign；或「签名放DATA里」开启时 sign 没放进载荷
106　签名有误见下方排查清单
105　时间差超限t 与服务器时间偏差超过「时间差效验」值，或客户端设备时间不准
108　未发现时间变量开启了时间差效验但没有提交 t

提示 以上错误响应本身也会按当前加密类型加密，接口返回的是一串密文，请先用相同算法解密再查看具体内容。

签名对不上时的排查清单

  1. 开启「调试模式」，拿到服务端签名原串，与客户端拼串逐字符比对
  2. 确认参与签名的键只有本次接口用到的那几个，没有多带参数
  3. 确认键的顺序与加密前的载荷完全一致
  4. 确认用的是应用 appkey，而不是 rc4_key
  5. 确认 t 是本次请求的时间戳（若开启了时间差效验）
  6. 确认载荷中的值不含 = 与 &（否则字段会被丢弃）
  7. 确认接口没有开启「独立配置」覆盖掉应用级的加密/签名设置

点我进群