接 Uber Direct：报价、下单配送、查状态
在 direct.uber.com → Developer → API credentials 复制应用的 Client ID 与 Client Secret，再从 Developer 页复制另一个单独的 Customer ID，在 Integration 里把取件地址按 JSON 字符串填好，测试换令牌通过即可发起 Uber Direct 配送。
Uber Direct 连接器用来从本系统发起 Uber Direct 同城配送：可以拿配送报价、按报价创建配送单、查询配送状态，也可以取消配送单。它只是末端配送连接——不把 Uber Eats 外卖平台的订单拉进本系统，也不做菜单或门店商品同步。报价与配送都走您自己的 Uber Direct 客户账号与取件地址。
前置条件#
- 一个 Uber Direct 账号，并且能进 direct.uber.com → Developer——您的应用与它的 API 凭证都在那里。
- 您能打开 direct.uber.com → Developer → 您的应用 → API credentials，那里显示 Client ID 与 Client Secret。Client Secret 只显示一次，所以要计划好当场复制进连接、并存到安全的地方。
- 您还有另一个单独的 Customer ID，在 direct.uber.com → Developer → Customer ID。它和 Client ID 是不同的值——连接两个都要用，用途不同。
- 您清楚门店或仓库取件地址的各个组成部分——街道地址、城市、州、邮编与国家——因为连接是把它作为一整段 JSON 字符串来填的，不是分开的字段。
拿凭证#
- 去 direct.uber.com → Developer → 您的应用 → API credentials。
- 复制该 API credentials 页上显示的 Client ID。
- 复制同一 API credentials 页上显示的 Client Secret。它只显示一次——现在就完整复制，并存到安全的地方。连接就是用这一对 Client ID＋Client Secret 去换访问令牌，范围是 eats.deliveries。
- 另外再单独去 direct.uber.com → Developer → Customer ID，复制 Customer ID。不要和应用页上的 Client ID 混淆：Customer ID 标识的是您的 Uber Direct 客户账号，配送请求都挂在它名下——API 路径本身就带它：/v1/customers/{customer_id}/deliveries。
填进 Integration#
- 打开 Integration → 连接器市场 → Uber Direct → 新建连接。
- client_id——必填，Client ID：粘贴 direct.uber.com → Developer → 您的应用 → API credentials 上的 Client ID。
- client_secret——必填，Client Secret：完整粘贴同一 API credentials 页上的 Client Secret。这是密码类型字段，作为秘密保存。记住它只显示过一次——照您当时保存的那份抄，不要凭记忆写。
- customer_id——必填，Customer ID：粘贴 direct.uber.com → Developer → Customer ID 上的 Customer ID。这不是 Client ID——配送请求挂在这个客户账号名下。
- pickup_address——必填，取件地址（JSON）：把取件地址作为一整段 JSON 字符串填入，格式必须正是这样：{"street_address":["20 W 34th St"],"city":"New York","state":"NY","zip_code":"10001","country":"US"}——把示例里的值换成您自己门店或仓库的值。注意 street_address 是一个方括号数组，所有引号必须是英文直引号。这个地址是下单配送时必填的；连接测试用不到它。
- pickup_name——可选，取件点名称：展示给取件环节看的名称，例如 Merchant 或您的门店名。pickup_phone_number——可选，取件点电话：能打通取件点的号码，例如 +15551234567。
测试连接#
点测试连接。这个测试就是换令牌本身：连接把您的 client_id 与 client_secret 发给 Uber 的登录服务（授权方式 client_credentials，范围 eats.deliveries），能拿回访问令牌就算通过。换令牌没有副作用——不创建配送单、不改变任何东西——所以它可以直接当测试用。如果返回里没有访问令牌，测试会以 BAD_JSON 失败：这次交换没有返回连接需要的东西，几乎总是意味着 Client ID 或 Client Secret 对不上。测试不用您的 pickup_address，也不检查 customer_id 是否真的能下配送单——所以地址填错、Customer ID 填错，测试照样可能通过，这些错误要到报价或创建配送单时才暴露。如果您还没保存任何凭证就点测试，得到的是模拟检查结果——保存真实凭证后再测一次，才是真实结果。
配 Mapping / 选模板#
Uber Direct 不需要订单 Mapping——它处理配送单，不处理订单。这里要确认的是每次请求都走的配送流程：先报价，再按报价创建配送单——创建配送单时一定会带上它来自的那份报价，所以没有绕过报价直接创建这一说。取件来自连接上的 pickup_address JSON，每次请求的送达地址、联系人与物品来自本系统里的运单。激活前，先跑一次真实报价、再给您自己的地址发一单测试配送，把报价、JSON 解析出的取件地址与送达信息和运单逐项对照。
激活#
激活后，本系统里的运单就能发起 Uber Direct 配送：连接按需换令牌，在您的 Customer ID 名下给配送报价，报价被接受后按报价创建配送单，配送状态回落到运单上，尚未取件的配送单可以取消。放手跑之前，先在 运行监控 / 日志里盯头几单真实配送——尤其是第一次报价，因为测试不检查取件地址、也不检查 Customer ID。
这个连接不做的事：不把 Uber Eats 外卖平台订单带进本系统，不同步菜单或门店商品，也不替您结算配送员费用或 Uber 账单。它只为您经它发出的运单做 Uber Direct 配送的报价、创建、跟踪与取消。
常见问题#
测试失败、没有拿回访问令牌——BAD_JSON
换令牌没有返回访问令牌，连接没有可用的东西，于是报 BAD_JSON。常见原因是 Client ID 或 Client Secret 对不上：其中一个复制错了、Secret 被截断了，或用的是另一个应用的凭证。
回到 direct.uber.com → Developer → 您的应用 → API credentials，从同一页重新复制这一对：Client ID 填 client_id，Client Secret 完整填 client_secret，且必须是同一个应用的。然后重新测试。
测试通过了，但报价或配送紧接着失败
测试只证明 client_id 与 client_secret 能换到令牌。它不用您的 pickup_address，也不检查 customer_id，所以 Customer ID 填错、或取件地址有问题，都能通过测试，要到真实报价或配送真正挂在那个客户账号下、从那个取件地址发出时才失败。
检查测试不覆盖的两个值：customer_id 拿 direct.uber.com → Developer → Customer ID 核对，pickup_address 按填入步骤里的 JSON 格式逐字核对。哪个错了改哪个，保存后重新报价。
我把 Customer ID 填进了 Client ID 的位置，或反过来填了
两个 ID 长得像，但干的活不同、来的页面也不同。Client ID 属于您的应用，和 Client Secret 一起用来换令牌。Customer ID 标识您的 Uber Direct 客户账号，并且出现在配送路径本身里：/v1/customers/{customer_id}/deliveries。填反了，两个字段虽然都填了，换令牌或配送请求照样失败。
把每个 ID 放回它自己的字段、按它自己的页面来源：Client ID 从 direct.uber.com → Developer → 您的应用 → API credentials 取、填 client_id；Customer ID 从 direct.uber.com → Developer → Customer ID 取、填 customer_id。保存后重新测试。
测试明明通过了，配送却因为取件地址失败
取件地址有问题时这样是正常的：连接测试根本不看 pickup_address，所以抓不到地址问题。地址只在真正下单配送时才用，那时一段格式不对的 JSON 字符串——street_address 写成了普通文本而不是数组，或从文档里粘来了弯引号——就会把请求挡下来。
照填入步骤里的格式亲手重写 pickup_address：{"street_address":["20 W 34th St"],"city":"New York","state":"NY","zip_code":"10001","country":"US"}，换成您自己的值——street_address 写成方括号数组、全程用英文直引号、JSON 前后不要多加任何文字。保存后重新下单配送。
我把 Client Secret 弄丢了——页面上不再显示了
API credentials 页就是这样工作的：Client Secret 只在创建那一刻显示一次。过了那个时刻，页面就不再显示它的值，所以没保存下来的 Secret 没法再从页面上读回来。
在 direct.uber.com → Developer → 您的应用 → API credentials 为同一个应用新建一个 Client Secret，这次当场复制，粘贴进连接的 client_secret，并留一份存到安全的地方。然后重新测试——连接会用新 Secret 换令牌。
创建配送单时提示要先有报价
这是 Uber Direct 的正常流程，不是您的值填错了：配送单永远是按报价创建的。报价先把配送细节与价格定下来，创建那一步再带上那份报价——没有跳过报价、直接创建的另一条路。
按顺序走流程：先为运单请求报价，核对报价与细节，接受后，再按那份报价创建配送单。如果报价已经过期，重新请求一份新报价，按新的创建，不要复用旧的那份。