DX API GPT API 中转接入
从模型、协议、分组三项核对开始,使用 OpenAI 兼容入口发起一次基础文本请求,再按实际用量确认计费。GPT 指定福利分组 0.05x 起,适用范围需要在价格页逐项核对。
先确认模型和分组都允许调用
进入模型与价格,选择准备调用的 GPT 模型,核对模型 ID、协议、所属分组和可用状态。展示名称用于阅读,请求中的 model 应填写控制台实际给出的模型 ID;不要凭模型名称自行拼接版本号或后缀。
同一个模型名称在不同分组下,权限、计费或上下文档位可能不同。创建或选择令牌时,需要让令牌可访问目标分组;页面能看到某个模型,不代表当前令牌一定有权限调用。模型是否支持工具、图片、流式输出或其他参数,也应以该模型详情为准。
- 复制控制台中的模型 ID,并确认有 OpenAI Chat Completions 兼容标记。
- 核对令牌的分组权限、余额及当前调用限制。
- 先发一个简短文本请求,避免同时加入工具、多模态和大量可选参数。
区分网站地址、Base URL 和请求端点
对于控制台明确标注为 OpenAI 兼容的模型,本指南使用的 Base URL 是 https://api.dxlingxiapi.top/v1。首页、价格页和教程页是网页入口,不应填到 API 请求配置中。
| 填写位置 | 内容 |
|---|---|
| 客户端的 Base URL | https://api.dxlingxiapi.top/v1 |
| 本页 curl 的完整 URL | https://api.dxlingxiapi.top/v1/chat/completions |
| 请求中的模型 | 该分组实际列出的模型 ID |
有些客户端会自动拼接 /v1 或请求路径。保存后查看其最终请求地址,避免出现 /v1/v1 或重复的 /chat/completions。这里的兼容示例不用于推定其他 API 端点也已支持。
OpenAI 兼容 curl 示例
以下是请求格式示例,不是某个具体模型的实测记录。将 API_KEY 和 MODEL_ID 替换为自己的令牌与已核对的模型 ID,再在本地终端执行。不要把带有真实令牌的命令发布到群聊或公开帖子。
curl --request POST \
"https://api.dxlingxiapi.top/v1/chat/completions" \
--header "Authorization: Bearer API_KEY" \
--header "Content-Type: application/json" \
--data '{
"model": "MODEL_ID",
"messages": [
{"role": "user", "content": "你好,请用一句话回复。"}
],
"stream": false
}'
先检查 HTTP 状态码、返回的错误信息和内容是否符合预期,再到控制台核对该次用量记录。基础请求通过后,逐项加入业务需要的参数;不要把一次文本请求成功当作所有模型能力都已验证。
0.05x 福利分组如何核价
0.05x 起只对应价格页标明的指定 GPT 福利分组。倍率以本站对应模型详情展示的基础价格为基准,具体模型、上下文档位、输入输出价格和是否可用,以实时价格页为准。
这个起始倍率不表示全部 GPT 模型、全部分组或全部上下文档位都采用同一价格,也不能换算成模型提供方的统一官方折扣。选择模型时,应同时查看输入、输出与上下文档位,避免只比较一个倍率数字。
从价格页进入目标模型详情,再与令牌使用的分组、调用日志中的模型和用量对应。累计充值、返利和盲盒等活动有各自条件,不能据此推定与福利分组自动叠加;实际资格和结算以站内当前配置为准。
按错误信息缩小排查范围
| 返回情况 | 优先检查 |
|---|---|
400 | JSON 是否有效、模型是否支持所加参数;先恢复本页基础文本请求。 |
401 | 令牌是否正确、有效,Authorization 是否采用 Bearer 格式。 |
403 | 令牌和目标模型的分组权限是否匹配,是否存在访问限制。 |
404 | 完整请求路径是否重复、模型 ID 是否来自当前分组。 |
429 | 当前限流、并发及错误正文;降低请求频率后再按限制重试。 |
这些是排查入口,具体原因仍需结合错误正文、余额和调用记录判断。向首页所列客服反馈时,附请求时间、模型 ID、分组、状态码和已脱敏的错误内容,不发送完整 API Key。
把通过的配置迁移到客户端
如果 curl 成功而客户端失败,先比较两边实际使用的地址、协议、模型 ID 和分组,再检查客户端是否自动添加路径或发送了额外参数。客户端配置可从新手接入开始,按照所选工具的说明填写;不要同时改动多个配置后再判断原因。
需要调用 Claude、Gemini 或 DeepSeek 时,先阅读对应指南。品牌名称相同或共用一个账户,都不足以证明请求协议、功能和分组限制相同。