上架流程实例

状态: 生效中
更新: 2026-09-05
适用范围: API Platform 提供方入驻的一次完整走查

成为服务提供方讲的是流程有哪几步。这一页补另一半： 每一步做完之后你会看到什么状态、下一步该你动还是该等、哪些看起来像卡住其实是正常的。

内容与截图都来自一次真实的完整入驻，不是设计稿。示例用的标识与平台表单里的占位符一致（acme.weather / primary.weather / weather.forecast），换成你自己的即可。

先说三件容易踩空的事

审核门是真的，不会自动跨越。 主体没到「运营中」之前，技术通道和商品的创建入口根本不出现。不必找绕过办法，也没有。

发布不是你能做的动作。 商品被批准之后，你会看到它停在「已批准」而没有公开版本 ——这是正常状态，不是卡住了。

每次决定都带着原因回到你的页面。 被要求修改或被拒绝时，理由就显示在对应对象上，不用另外问。

一、创建服务主体

填写主体标识、显示名与公开业务说明，保存草稿，然后提交。

标识创建后不可更改，全站唯一，小写英文、数字、点或中划线。它会出现在公开目录里，按对外品牌取名，不要用内部代号。

公开业务说明是审核判断的主要依据。写清楚你提供什么能力、数据从哪来。承诺越具体，审核越快——含糊的描述只会换来一次「要求修改」。

创建第三方 Provider 申请的表单，已填入 Provider code、显示名称与公开业务说明 — 创建主体的表单。Provider code 是公开标识，创建后不可更改。


提交后状态	已提交
下一步	等待主体审核结果

创建时当前账号自动成为首位 OWNER，结算归属由平台建立，不在表单里选择。

Provider 详情页，状态徽标为已提交，页面下方提示等待主体进入 ACTIVE — 提交之后。创建者已经是 OWNER，而 Connections 与 Listings 的入口还没有出现。

二、等待主体审核

状态从「已提交」变为「主体审核中」，说明审核已经开始。


通过后状态	运营中
解锁	技术通道与商品的创建入口

Provider 详情页，状态徽标为运营中，页面下方出现 Connections 与 API Service Listings 两个区块 — 批准之后的同一个页面。两个区块出现了，内容都还是空的。

主体批准不代表你的通道或商品被认可，后面两道各自独立。

三、创建技术通道

填写通道标识、显示名、HTTPS 地址与接入凭据，保存草稿。

地址只能是公网 HTTPS origin：不带路径、查询串、userinfo 或自定义 Header，也不接受私网例外。执行与对账路径、Adapter 与网络策略由平台固定，你改不了也不用填。

凭据由你自己定，不是平台签发给你的。 你先把它配到自己的服务上，再在这里提交同一个值。平台加密保管并按版本号记录，之后任何页面都不会再回显。轮换时只追加新版本，不覆盖历史绑定。

创建 Connection 草稿的表单，已填入 connection code、显示名称、HTTPS endpoint origin、接入凭据与运维备注 — 创建通道的表单。凭据字段写入后不再回显，页面上也没有查看入口。


保存后状态	连接草稿

保存之后。地址被规范化成带端口的 origin，profile 从 1 开始计数。

四、自己跑契约一致性检查

提交核验之前先跑这个。 平台会真的调用你的地址，逐项验证是否符合调用协议。可以反复运行，不触发任何审批，不会消耗你的额度。

检查覆盖九项：

检查	code	期望
存活探测	`HEALTH_LIVE`	返回 200
就绪探测	`HEALTH_READY`	返回 200
执行面校验凭据	`CREDENTIAL_REQUIRED`	无凭据的请求返回 401
执行响应信封合规	`EXECUTE_ENVELOPE`	信封与 transport status 一致
同 key 重放稳定	`IDEMPOTENT_REPLAY`	同一幂等键重放返回相同结果
同 key 换 payload 冲突	`FINGERPRINT_CONFLICT`	返回 409，明确标为幂等冲突
已知 key 可对账	`RECONCILE_KNOWN_KEY`	对账结果稳定
拒绝未知 envelope 字段	`UNKNOWN_FIELD_REJECTED`	返回 400
未知 key 不谎报成功	`RECONCILE_UNKNOWN_KEY`	返回「接受前可重试」，而不是编一个结果

code 是稳定标识，也是控制台里显示在每条结果旁边的那一串。哪一项没过，照着它就能找到自己服务里对应的那段实现。

契约一致性检查面板，九项全部通过，每项显示检查名称、实际观察到的结果与稳定 code — 九项全绿的样子。每项都写出实际观察到的结果，而不只是通过或失败。

最后一项最容易被忽略：平台问一个它没见过的键时，正确回答是「这次调用我没接受过」，不能返回成功或失败。谎报会让平台把不存在的调用当成已完成。

九项没有全绿就提交，只会在下一步被退回。协议细节见实现你的服务。

五、提交通道核验

提交后通道进入只读，你改不了显示名、地址或凭据。


提交后状态	已提交 → 核验开始后接入核验中
通过后状态	可用于发布

Connection 详情页，状态徽标为已提交，页面提示 Connection 当前只读 — 提交之后。编辑表单消失，改地址或换凭据都要等这一轮核验有结果。

契约检查没有全绿的通道不会被批准。这一步不做业务判断，只看技术契约。

六、创建商品并提交审核

填写商品标识、显示名、报价与服务说明。

报价填的是调用方看到的总价。 你不填自己和平台各拿多少——分账由发布时生效的费率策略计算，并冻结进那一次发布的快照。

创建 API Service Listing 的表单，已填入 listing code、显示名称、报价 points、服务说明与请求/返回 schema — 创建商品的表单。请求与返回 schema 随修订一起审核，并冻结进发布版本。

提交后内容锁定，撤回即回到草稿。


提交后状态	审核中
下一步	等待内容判断

Listing 详情页，状态徽标为审核中，页面提示修订正在审核并提供撤回入口 — 提交之后。撤回是你自己的动作，撤回即回到草稿。

七、等待商品审核

这一步是业务判断，不是技术检查——技术部分在第四、五步已经做完。判断依据是你写的服务说明与主体声明是否一致、报价与能力是否相称。


通过后状态	已批准，但公开版本仍是 0 项

Listing 详情页，审核事件依次为 CREATED、SUBMITTED、APPROVED，右侧「已发布版本」显示 0 项 — 这是最容易被读成「卡住了」的一屏：已批准，公开版本 0 项。

看到「已批准」而目录里还没有你的服务，是正常的。差最后一步。

八、等待发布

批准之后由平台创建不可变发布。Adapter、你的报价、当时的平台费率与所绑通道一并冻结进这一版的快照。


发布后状态	已发布
结果	服务出现在公开目录，可被调用

Listing 详情页顶部的绿色提示：当前修订已有不可变发布，12 points，右侧是创建下一修订的按钮 — 发布之后。这一版不能再改，能做的只有创建下一修订。

公开服务目录中的服务页，列出 weather.forecast 的 v1 版本、12 points 与 PUBLISHED 状态 — 同一时刻的公开目录。版本、价格与状态都是这一次发布冻结下来的。

版本号被永久占用，内容不能修改或回收。要改价或改内容就创建新修订、发布新版本；旧版本继续按原契约服务已经在用它的调用方。

整条链路的状态对照

阶段	你的动作	之后的状态	该谁动
主体	创建并提交	已提交	你
主体	—	主体审核中	等平台
主体	—	运营中	等平台
通道	创建	连接草稿	你
通道	跑契约检查	不改状态	你，可反复
通道	提交核验	已提交 → 接入核验中	你，然后等平台
通道	—	可用于发布	等平台
商品	创建并提交	审核中	你
商品	—	已批准	等平台
商品	—	已发布	等平台

被退回怎么办

要求修改和拒绝都必须带原因，原因显示在对应对象的页面上。

商品被要求修改时回到草稿，改完重新提交，走同一条审核路径。通道被要求修改时同理。 主体被拒绝不影响你重新申请，但同一个标识不会被释放。

当前的处理速度取决于人工进度，技术检查那一环已经自动化并且你可以自助反复运行—— 先把九项跑绿，能省掉绝大多数来回。

当前还做不到的事见目前的限制。