Eventbrite API 退款请求返回 403 Error

2026-10-24支付小周

结论

POST /refund_requests/ 返回 403 NOT_AUTHORIZED，通常与 PHP 数组或 json_encode() 无关，而是当前 OAuth token 或应用没有访问退款请求接口的权限。

能调用 event、ticket 等接口，不等于拥有 refund request 权限。退款涉及资金操作，可能受到更严格的限制，例如要求特定账户身份、订单归属关系，或由 Eventbrite 单独向应用授权。

排查和解决步骤

1. 确认 token 对应的用户身份

先检查 token 是否属于该活动的主办方账户，以及该账户能否管理目标订单。需要确认：

订单属于当前活动或组织；
token 不是由其他 Eventbrite 账户生成的；
协作者账户有足够的订单和退款管理权限；
活动、订单与收款主体之间不存在跨组织关系。

如果改用活动所有者生成的 token 后请求成功，说明问题出在账户权限，而不是请求格式。

2. 确认应用是否获准访问退款接口

/refund_requests/ 可能并非向所有 API 应用开放的通用端点。应用缺少相应权限时，即使同一个 token 可以创建或更新活动，请求仍会收到：

403 NOT_AUTHORIZED
You do not have permission to access the resource you requested.

这种情况无法通过增加普通请求参数解决，需要向 Eventbrite 开发者支持确认：

当前应用能否使用 POST /refund_requests/；
是否需要额外的 OAuth scope、应用审核或合作伙伴权限；
该端点目前是否仍向第三方应用开放。

如果 Eventbrite 没有向该应用开放权限，只能在 Eventbrite 后台处理退款，或改用其当前支持的退款流程。

3. 不要把“退款请求”理解为“直接退款”

从名称看，POST /refund_requests/ 用于创建退款申请，不一定会直接把款项退回原付款方式。即使应用获得了接口权限，退款申请也可能仍需主办方审核。

如果实际需求是让主办方直接执行退款，应先确认 Eventbrite 是否为当前账户和应用类型提供了正式的退款端点，不能直接把 /refund_requests/ 当作执行退款的接口。

4. 确认权限后再校验请求格式

确认应用有接口权限后，再按照当前 Eventbrite API 文档的要求发送 JSON。除非客户端库或接口文档明确规定某个字段必须是 JSON 字符串，否则不要提前对嵌套字段单独执行 json_encode()。

可以先使用结构化数组：

<?php

$eventBriteModel = new zerolfc\eventbrite\HttpClient(TOKEN);

$refundItems = [
    [
        'order_id' => $eventbrite_order_id,
    ],
];

$response = $eventBriteModel->post('/refund_requests/', [
    'from_name'  => $attendee_name,
    'from_email' => $attendee_email,
    'items'      => $refundItems,
    'message'    => $message,
    'reason'     => $reason,
]);

具体的字段结构、是否还需要订单项标识，以及客户端会不会自动序列化 JSON，都应以所用 API 版本和 PHP 库的说明为准。如果该库要求提交表单字段，items 才可能需要编码：

'items' => json_encode($refundItems, JSON_THROW_ON_ERROR),

请求格式有误时通常更容易出现 400 Bad Request。当前响应明确是 403 NOT_AUTHORIZED，所以应先处理授权问题。

注意事项

不要反复修改 from_email，也不要伪造参加者身份来绕过权限检查。
确认请求使用了正确的 API 基础地址和版本前缀，例如检查客户端是否会自动添加 /v3。
记录响应头中的 request ID，联系 Eventbrite 支持时一并提供。
不要在日志、工单或公开代码中泄露 access token。
如果官方确认该接口只向特定合作伙伴开放，修改客户端代码也无法解除这一限制。