Castle（反欺诈请求令牌）

Castle（反欺诈请求令牌） 是 Castle 的反欺诈请求令牌（不是验证码）。⚠ **什么都看不到。** Castle 不是一个验证码 —— 它是风控 SDK，在后台给每个敏感请求生成一个令牌，用户全程无感。

正在查询可用性…$0.97 / 1K 次按成功计费，失败退款

接口规格

项目	值
type	`castle`
必填参数	`website_urlwebsite_keymetadata`
可选参数	`countuser_agentproxy`
返回	一组 token（`solution.tokens`）
怎么用这个解	一批可回填的 Castle 请求令牌（按你要的 count 个）
价格	$0.97 / 1K 次 —— 按成功计费，没解出来退款
厂商文档	Castle 官方文档

参数去页面哪里取

下面全部是可以直接照做的定位方法 —— DOM 属性名、JS 全局变量名、script 上的 query 参数。

必填 website_url，可选 count（一次要几个令牌）与 user_agent。

怎么确认页面上有 Castle

看脚本域名 castle.io：

[...document.scripts].map(s=>s.src).filter(s=>/castle\.io/.test(s))

⚠ `count` 的语义与别处不同

它决定这次返回几个令牌（1–49，默认 1），不影响计费 —— 按次收、不按令牌数。客户在后续多个请求上逐个用掉，用完再来取。这是因为 Castle 的令牌一次一用，批量取能省往返。

调用示例

一个端点解全部验证码类型 —— 换一种验证码只改 type 这一个字段。

请求

curl -X POST https://api.everyinfra.com/api/v1/captcha \  -H "Authorization: Bearer omg_你的KEY" \  -H "Content-Type: application/json" \  -d '{"type":"castle","website_url":"<website_url>","website_key":"<website_key>","metadata":"<metadata>"}'

响应

{  "solution": {    "tokens": "…"  },  "billing": { "charged": true, "credits": 70 }}

怎么确认目标站用的就是它

页面里的 Castle SDK 采集设备与行为信号，生成一个请求令牌；站点把令牌随注册/登录/下单请求发给自己的后端，后端再拿它去 Castle 查风险评分。所以它防的是**账号接管与欺诈**，不是「你是不是机器人」这一个二元判断。

容易搞混的

⚠ 与各类验证码本质不同：验证码是「过这道题拿凭证」，Castle 是「给这次请求附一个风险令牌」。目标站同时上了两者时，两边都要处理。

常见部署场景

SaaS 与金融科技的注册、登录、改密、支付环节
把风控做在应用层而不是边缘的团队
常与其他边缘防护叠加使用

已知的坑

它不是验证码：解出来的是请求令牌，用途是过风控评分，不是过一道人机题。

`count` 一次给多个令牌但只收一次钱 —— 需要连续发多个请求时一次多取几个更划算。

令牌一次一用，用过就作废。

这是反欺诈 SDK 的请求令牌，不是一道要解的题 —— 没有图、没有交互，我们生成一批目标站会接受的令牌

一次拿回的是一批（1–49 个，count 控制），不是一个。客户在后续多个请求上逐个用掉，用完再来取

常见问题