Uber Direct 报价的15分钟有效期，和预计送达不是同一个时间

门店看到配送接口返回一个时间，先要弄清它是在说“这份报价还能用多久”，还是“货物预计何时送到”。两者可以同时出现在报价响应中，却回答不同问题。把报价倒计时显示成送达倒计时，会让顾客以为已经取得了文档并未给出的时效承诺。

Uber Direct 官方 FAQ 对生成的 Quote 与 quote_id 有效多久，给出的回答是15分钟。Get Started 页的报价示例也分别列出 created 和 expires：示例中前者为02时36分57.776秒，后者为02时51分57.776秒，均带 UTC 标记。相差15分钟的是这两个字段，而不是送达过程的用时。

同一个示例另外列有 dropoff_eta、duration 和 pickup_duration。它们与 expires 并列存在，已经提示读者不能把到期时刻改名为预计送达时刻。原文将响应描述为配送时间估计和费用报价，而示例的 dropoff_eta 晚于 expires；这并不构成矛盾，因为报价被使用的窗口与配送估时不是同一段时间。

页面中的操作关系也很明确：先请求报价，再在创建配送的请求中使用前一步得到的 quote_id。因此，取得一个报价对象只说明已有这一阶段的返回结果，不能据此声称配送已经创建，更不能从报价时刻倒推配送员已取货。这里关注的是报价与后续请求的分工，不展开配送状态表。

假设客服页面同时写着“报价于10时15分到期”和“预计10时40分送达”，两句文字可以各自保留含义。若把它们压缩成“还剩15分钟送达”，就把报价有效窗口移到了另一个对象上。这是本文自拟的界面文案示意，不是一次真实 API 测试，也没有证明实际订单能在某时刻送到。

阅读示例还应保留时间背景。官方入门页响应里的日期是2023年，金额、分钟数和地址用于演示数据结构；本文没有把它们当作2026年的实时报价、当前费率或服务表现。15分钟这一表述来自本次读取的 FAQ，具体业务仍应以对应请求和适用产品资料为准。

对城市配送的信息展示而言，分别标出“报价到期”与“预计送达”，比只留一个时间更清楚。本文于2026年10月12日核读两份官方文档，未创建订单或处理支付，也不据这些字段判断赔付条件。一个时间值的意义，取决于它跟随的字段和对象。