交付照片在哪里可见：Uber Direct后台七天与接口三十天的不同范围

配送资料写着交付照片保留多久时，渠道也应当跟着期限一起保留。Uber Direct《Proof of Delivery》的Picture段同时提到Direct Dashboard和API：照片在后台保留七天，通过API可取得三十天。[1] 同一照片出现两个期限，是文档对不同获取渠道的说明，不能只摘其中一个数字，再用它覆盖全部情形。

Picture段还有两个具体联系。Leave at Door作为交接方式时，照片会自动启用；照片可在Dashboard中访问，也可以通过接口返回的URL联系到。与此同时，文档将把照片展示给顾客的责任放在商户自己的应用上。于是，配送服务已有照片、商户取得文件位置和顾客在商户应用里看见照片，是可以衔接却各有内容的几件事。后台存在图片，尚不能单独证明顾客界面已经呈现。

七天与三十天的差别，最适合放在获取方式的背景中理解。一份面向客服的服务说明如果只写“照片保存三十天”，可能让只使用Dashboard的人员误以为后台具有同样的查看期限；如果只写七天，又会省掉文档另列的接口可取得范围。这里的分析只说明为何两个渠道应分别标注，没有查询任何真实图片，也没有从获取期限推断服务器此后的物理删除安排。

同页的Signature段另说，签名核验图像可通过Proof of Delivery接口取得，图像保留三十天。这个段落的对象是签名图像，Picture段的七天则明确联系照片后台。二者同属证明资料，却没有被文档写成所有文件在所有渠道一律七天。整理资料时，文件对象与渠道一起出现，才能使期限具有完整含义。

响应示例又把要求与文件分开。CreateDelivery及GetDelivery所列的verification_requirements，描述照片、签名等核验要求；配送成功完成后，delivered事件及GetDelivery响应才通过外部链接引用证明文件，照片和签名图像各有image_url。要求中出现picture，与已经返回某张照片的文件链接，是示例中的不同信息位置。本文据此解释文档结构，不调用接口、采集签名或确认某次交付已经完成。

对城市配送内容人员，这份资料可以形成一份具体说明：讨论哪类证明文件、从哪个渠道取得、原文给该渠道多长时间，以及商户如何在自己的应用中承担呈现联系。首次发布日期未知，本文不涉及身份证、年龄核验、受限商品、隐私留存义务或赔付责任，也不提供实际配送步骤。它保留的是照片与签名资料的获取范围，而非用一张图替整条运输过程作保证。