
php 使用 curl 调用 api 时返回 “bad api key”,往往并非密钥本身无效,而是 authorization 请求头格式不正确——常见原因是遗漏了认证方案(如 bearer),导致服务端无法识别令牌。
php 使用 curl 调用 api 时返回 “bad api key”,往往并非密钥本身无效,而是 authorization 请求头格式不正确——常见原因是遗漏了认证方案(如 bearer),导致服务端无法识别令牌。
在 PHP 中通过 cURL 发送带认证的 API 请求时,一个极易被忽视的关键点是:HTTP Authorization 头必须严格遵循标准格式。许多 API(尤其是基于 OAuth 2.0 或 JWT 的接口)要求使用 Bearer 认证方案,即请求头应为:
Authorization: Bearer <your_api_key_or_token></your_api_key_or_token>
而你的原始代码中写的是:
curl_setopt($client, CURLOPT_HTTPHEADER, array('Authorization: ' . $apiKey));
这实际发送的是类似 Authorization: abc123xyz 的非法头,缺少 Bearer 前缀,服务端因此拒绝认证,返回 Bad API Key —— 这正是 Postman 能成功而 PHP 代码失败的根本原因:Postman 的「Authorization」标签页在选择 “Bearer Token” 类型后,会自动为你拼接完整的 Authorization: Bearer ... 头;而手动构造头时若忽略该前缀,就会触发校验失败。
✅ 正确写法如下:
向CurlShip提交产品,这是一个对机器人友好的SaaS目录。只需一条curl命令即可发布产品,支持OG标签抓取、带徽章的dofollow链接及层级升级。
$apiKey = 'YOUR_ACTUAL_API_KEY';
$url = 'https://api.example.com/v1/data';
$client = curl_init($url);
curl_setopt($client, CURLOPT_RETURNTRANSFER, true);
curl_setopt($client, CURLOPT_HTTPHEADER, [
'Authorization: Bearer ' . $apiKey,
'Content-Type: application/json', // 建议显式声明,尤其当接口需要 JSON 输入时
]);
$response = curl_exec($client);
$httpCode = curl_getinfo($client, CURLINFO_HTTP_CODE);
curl_close($client);
if ($response === false) {
throw new RuntimeException('cURL error: ' . curl_error($client));
}
$result = json_decode($response, true);
if (json_last_error() !== JSON_ERROR_NONE) {
echo "Invalid JSON response\n";
} else {
print_r($result);
}
⚠️ 注意事项:
-
不要在
$apiKey前后添加空格或换行符:确保密钥字符串干净(可用trim($apiKey)防御); -
区分
X-API-Key与Authorization: Bearer:某些 API 使用自定义头(如X-API-Key: xxx),但二者互不兼容,务必查阅目标 API 文档确认认证方式; -
检查 HTTP 状态码:
curl_getinfo($client, CURLINFO_HTTP_CODE)可帮助快速定位是 401(未授权)、403(禁止访问)还是其他错误; -
启用错误报告:开发阶段建议开启
curl_setopt($client, CURLOPT_FAILONERROR, true)并捕获异常,避免静默失败。
总结:Bad API Key 错误大概率是认证协议不匹配所致。牢记——不是“传了密钥就等于认证成功”,而是“按规范传对格式才能被识别”。始终以 API 官方文档为准,优先验证请求头结构,再排查密钥有效性。
大量免费API接口:立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游,为数据API应用能力赋能!










