OPEN PLATFORM

让你的服务
在 REACHE 对话中被需要

这不是一个需要用户主动打开的小程序平台。当用户在 REACHE 对话中提出打车、订票、查地图、订机票或酒店等真实需求时，系统才会按意图被动唤起经审核的服务 API，并在对话内呈现相应的场景化 UI。

申请接入 看接入方式

服务如何进入真实场景

没有独立入口、应用列表或小程序首页。服务跟随用户需求出现，完成后回到同一段对话。

行

出行与打车

用户说出出发地、目的地或时间后，REACHE 可调用出行服务商的询价、车型、下单与行程 API，并呈现选车和订单进度 UI。

游

景区票务与地图

用户计划前往景区时，可按需唤起园区门票、预约时段、导览地图与路线服务，让查询和预订在当前对话中连续完成。

旅

机票与酒店

航空、酒店或综合旅行服务商可开放搜索、库存、价格与订单 API，由 REACHE 结合日期、地点和偏好呈现筛选与确认 UI。

轻量接入，只需开放服务能力

服务商无需开发独立小程序或复制一套前端。提供合规资质、现有服务 API 与测试环境，其余由双方按场景完成联调。

提交资质与范围

提供企业、业务许可、服务地区、隐私政策与联系人，由后台审核服务商资质和可接入范围。

开放现有 API

提供接口文档、鉴权方式、测试环境与错误码；可使用签名、令牌或 OAuth，无需重做业务系统。

确认能力与 UI

双方约定可调用能力、字段、操作按钮和品牌元素。UI 由 REACHE 在对话场景中呈现，不形成独立小程序。

联调审核后上线

完成沙箱联调、异常与敏感操作验收，经后台审核后按批准的服务范围被动唤起。

// 轻量接入描述示例：出行服务商继续使用自己的业务 API
{
  "service_id": "acme.ride_hailing",
  "capabilities": ["quote", "create_order", "order_status", "cancel_order"],
  "base_url": "https://api.acme.com/reache",
  "auth": "signed_request",
  "scenario_ui": ["vehicle_selector", "price_quote", "trip_status"],
  "confirm_before": ["create_order", "cancel_order"]
}

安全与边界

服务只在用户需要时出现，接入范围、数据使用和关键操作都必须清晰可控。

用户意图触发，不主动打扰。没有未经请求的弹窗、导流或营销触达；只有用户表达相关需求时，服务才可能被动唤起。
服务商资质与能力范围先审核。企业主体、行业许可、服务地区和接口用途经后台审核，未获批准的能力不得调用。
最少数据与明确授权。只传递完成当前服务所必需的信息；涉及账号、位置或个人信息时，按场景取得用户授权。
敏感操作必须确认。下单、支付、取消等可能产生费用或不可逆影响的操作，在执行前向用户展示关键信息并确认。
交易履约可追溯。价格、库存、订单状态和售后责任由对应服务商提供；接口失败时如实反馈，不把失败展示为成功。

审核与上线流程

REACHE 对服务商主体和每项能力分别审核；通过不等于无限开放，正式调用始终受批准范围约束。

P1 · 申请

主体与业务审核

核验企业、行业资质、服务范围、隐私政策与对接负责人。

P2 · 对接

接口与沙箱联调

确认接口、鉴权、限流、回调、错误码和测试数据。

P3 · 验收

场景与 UI 验收

验证触发条件、展示字段、关键确认、失败降级和履约链路。

P4 · 上线

按范围开放

审核通过后上线，并持续监测稳定性、合规性与服务质量。

申请接入

留下服务或公司名称与联系方式。我们会先了解业务资质、可开放 API 和适用场景，再安排对接审核。