推荐 API(ref_id)
在购买请求中附加 ref_id,激活获批后即可获得收入分成。
工作原理
每笔 ref_id 奖励背后的机制。
每笔携带你的 ref_id 且获批的激活,你可获得其收入的 5%。唯一的例外:如果该笔销售的利润非常低,奖励将被限制为该利润的一部分。此限制至今从未生效。
只有激活获批(即验证码确实到达)时才会产生奖励。被取消或退款的激活不会产生任何收益。
奖励会立即计入你的钱包余额,无需等待期。
API 收益是钱包余额:没有最低额度,也没有提现申请流程,但不能兑换为现金。可用于平台上的任何产品。
发送 ref_id
两条 API 通道接受相同的推荐码,只是传递方式不同。
现代 API(v1,JSON 请求体)
curl -X POST "https://smsbulk.net/api/v1/activations" \
-H "x-api-key: YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{
"serviceCode": "wa",
"countryIso": "US",
"ref_id": "K7M2QXWP"
}'{
"id": "act_9f1c...",
"status": "PENDING",
"phoneNumber": "+1...",
"referral": {
"accepted": true,
"reason": null
}
}SMS-Activate 兼容通道(查询参数)
curl "https://smsbulk.net/stubs/handler_api.php\
?api_key=YOUR_KEY&action=getNumber&service=wa&country=187&ref_id=K7M2QXWP"ACCESS_NUMBER:12345678:79991234567合作伙伴最容易搞错的两条规则
这两道防护机制用于防止自我返利和重复返利。如果奖励没有出现,原因几乎总是其中之一。
自我交易会被拦截
如果 ref_id 属于发起购买的同一账户,则不会产生任何奖励。把自己的 ref_id 用在自己的流量上永远不会获得佣金。
已绑定的账户会被忽略
如果买家注册时已经通过同一合作伙伴的推荐链接绑定,那么在购买时再发送该合作伙伴的 ref_id 会被忽略:绑定关系已经存在,因此不会产生第二笔奖励。发送另一个合作伙伴的 ref_id 仍会正常生效。
无效的 ref_id 永远不会阻止购买
未知、格式错误或已失效的 ref_id 会被静默忽略。无论推荐码是否有效,购买始终会正常完成。
v1 响应中的 referral 字段
只有请求本身发送了 ref_id,POST /v1/activations 才会包含 referral 对象。从不发送该参数的请求,响应结构与以往完全一致。
- accepted: true 表示 ref_id 已被接受并关联到本次激活。奖励本身会在激活获批后才写入。
- accepted: false 表示没有生成奖励,请查看下方的 reason 值。
reason 取值
| reason | 含义 |
|---|---|
| unknown_code | ref_id 不匹配任何合作伙伴的推荐码。反复尝试无效推荐码会被限速。 |
| self_dealing | ref_id 属于发起购买的同一账户。 |
| already_referred | 买家在注册时已经绑定了同一合作伙伴,因此该推荐码被忽略,而不是视为错误。 |
| referrer_inactive | 该 ref_id 背后的合作伙伴账户已停用或被封禁。 |
SMS-Activate 兼容通道没有 referral 字段
该协议返回的是纯文本行,例如 ACCESS_NUMBER:id:phoneNumber,而不是 JSON,因此没有字段可以携带 accepted/reason 反馈。ref_id 在这条通道上依然以完全相同的方式生效,只是你无法在响应中看到结果,请改为在合作伙伴面板中查看确认信息。
