php 使用 curl 调用 api 时返回“bad api key”，通常是因为 authorization 请求头格式不正确——缺少标准认证方案（如 bearer），而 postman 自动补全了该前缀，导致本地代码与工具行为不一致。
php 使用 curl 调用 api 时返回“bad api key”，通常是因为 authorization 请求头格式不正确——缺少标准认证方案（如 bearer），而 postman 自动补全了该前缀，导致本地代码与工具行为不一致。
在实际开发中，许多 RESTful API（如 Stripe、Auth0、自建 OAuth2 接口等）要求 Authorization 请求头严格遵循 RFC 7235 规范，即采用 <scheme><credentials></credentials></scheme> 格式。常见 scheme 包括 Bearer（用于 token）、Basic（用于 base64 编码的用户名密码）等。你当前的代码：
curl_setopt($client, CURLOPT_HTTPHEADER, array('Authorization: ' . $apiKey));生成的是形如 Authorization: abc123xyz 的非法头，服务器无法识别该凭据类型，因此拒绝请求并返回 “Bad API Key”。
✅ 正确写法应显式指定认证方案（绝大多数 token 类 API 使用 Bearer）：
CurlShip Directory Submission
下载
向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 body 时
]);
$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) {
throw new RuntimeException('Invalid JSON response');
}
echo "HTTP Status: $httpCode\n";
print_r($result);⚠️ 注意事项：
立即学习“PHP免费学习笔记（深入）”；
- 不要将
Bearer写成bearer或BEARER—— 虽然部分服务端兼容大小写，但规范要求首字母大写，建议严格遵循； - 若 API 文档明确要求其他 scheme（如
X-API-Key、Apikey或Token），请以文档为准，而非通用惯例； - Postman 的 “Authorization” 选项卡中选择 “Bearer Token” 时，会自动拼接
Authorization: Bearer xxx，这正是它能成功而你的代码失败的根本原因； - 建议始终检查
curl_getinfo($client, CURLINFO_HTTP_CODE)获取真实 HTTP 状态码（如 401 Unauthorized），避免仅依赖响应体判断错误类型。
总结：API 密钥本身无误，问题出在请求头语义缺失。修复关键在于补全标准认证 scheme —— 对于 token 类密钥，99% 场景下应使用 Bearer 前缀。养成查阅 API 官方文档中 “Authentication” 章节的习惯，是规避此类问题最有效的方式。
