当前接口状态 · 正常

发送短信验证码

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

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

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

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

返回格式： JSON

请求方式： GET/POST

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

请求参数说明：

名称 变量 必填 类型 说明
接口 api 是 GET 填写smssend
应用 app 是 GET 填写后台应用APPID
手机号 phone 是 GET/POST 填写手机号
类型 sms_type 是 GET/POST 填写一种类型register/login/reset
时间戳 t 否 GET/POST 如果开启了[时间差效验]需提交此项
数据签名 sign 否 GET/POST 如果开启了[数据签名]需提交此项

返回参数说明：

名称 类型 说明
code String 返回状态
msg String 返回信息

返回示例：

{
    "code": 200,
    "msg": "验证码已发送，请注意查收"
    "time":1582107375
}

错误码格式说明：

名称 类型 说明
101 String 应用不存在
102 String 应用已关闭
171 String 接口维护中
172 String 接口未添加或不存在
115 String 账号已存在
117 String 该IP已注册
174 String 该QQ已存在
116 String 账号长度5~11位，不支持中文和特殊字符
119 String 密码长度需要满足6-18位数,不支持中文以及.-*_以外特殊字符

代码示例：

暂未添加示例代码

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

开启后，请求参数与返回数据都按该算法处理。加密模式下业务参数不再直接放在 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. 确认接口没有开启「独立配置」覆盖掉应用级的加密/签名设置

点我进群