什么是 

Universal API?

在我动笔写这篇文章时，我也没有决定好到底用哪个称谓称呼这群公司：Universal API、Unified API、Data Aggregator、Data Normalization Vendor、Modern Integration Platform as a Service……

我最终选了 Universal API 这个最安全的选项，它理解起来实际上很简单：一个 API，它通过集成上游系统的 API 或通过屏幕抓取的方式连接到了不同的数据源，将获得的数据格式统一标准化，并且保持监控和维护来防止这些连接断掉或出错。Plaid 是最典型的代表，它左手连接了 12000 个银行或数据合作伙伴，右手则通过一个 API 让 6000 多家 Fintech 客户能够接入其用户的银行账户数据。

将这个过程简要的可视化将会是这个样子：

鉴于 API 领域有许多玩家、完成相似（但又大不相同）的数据流动过程有许多方式，我希望在一开始指出本文所讨论的 Universal API 与几类易混淆的玩家的差距：

它不是企业服务总线或是上一批 integration Platform as a Service 平台。

被 Salesforce 以 65 亿美元收购的 Mulesoft 是这类公司的代表，它也在帮助企业解决集成问题。主要的差异在于 Mulesoft 解决的是企业内部系统间的集成，而 Plaid 或 Merge 这样的 Universal API 则解决跨企业的集成问题。因此 Mulesoft 某种程度上是 Plaid 的上游，帮助 HSBC 这样的银行更好地整合系统和数据以 API 地形式对内支撑业务和对外提供服务。

它不是 RPA 或者 Zapier 这样的 integration Software as a Service 。

当你使用的 Google Calendar、Slack、Salesforce 等软件都开放了 API，使用 RPA 和 Zapier 可以解决部分问题。这个过程甚至不需要严肃的后端工程师参与，运营也可以自己创建一个日历和 IM 之间的自动化流程。但是这种集成并没有真的让两个系统互相“通话”，而是依靠“if-then”来执行，它适用于轻量的团队、部门流程自动化，缺少对实时性、复杂的业务逻辑、流程多了以后维护与管理的适配。

它的意义不是“卖数据”或是“另类数据提供商”。

二者的区别微妙但巨大，Universal API 所连接的数据类似 OLTP 数据，而典型的另类数据（海量投研报告、零售渠道消费者数据、招聘统计数据等）则更偏向分析型数据。这种分析型的数据不强调实时和强一致性，主要用于喂给机器学习或者辅助金融决策，而不是用来支撑实时业务。

02.

Universal API 的市场版图

上图中的公司按照其业务特点可以分为两类：

· 深入垂直行业，比如上图中的 Plaid 和各个领域的 Plaid for &%#；

·横向聚合数据，即上图中的 Integration Platform as a Service，代表性的做法是 Merge，它并不深入某一类系统和数据，而是横向地为不同的系统都构建 Universal API，从 HRIS、Ticketing 到 CRM；Tray.io 和 Workato 正在跟进这种做法，所以它们也勉强被放进来；WorkOS 的业务略有不同，但我也把它归入此类，它主要帮助企业构建面向大型企业客户销售时所需要的集成。

从用例的视角出发，Universal API 能解决几类核心问题（我以重要性由高到低的顺序将它们罗列，但通常同一个 Universal API 对于不同业务的客户所对应的用例也不同，并且它们并不是互斥的）：

1. 使核心业务关键环节得以进行

Universal API 是某些公司核心业务能够成立的关键原因，最典型的例子是 Plaid 和 Pinwheel。

大部分人对 Plaid 相对熟悉，大量的个人财务状况管理和消费者信贷应用都在最根本层面上依赖 Plaid 所建立的基础设施。如果失去 Plaid 和它背后的银行数据，它们的主业将无法开展。

Pinwheel 则是雇员授权的薪酬数据和 HRIS 系统的 Universal API，它的核心用例之一是 Direct Deposit（将工资收入直接打入银行账户，而不是每个月收支票存工资）。挑战者银行的业务极度依赖这一点 —— 如果无法争取到 Direct Deposit，它们就不是用户的主账户，不论是储蓄额、用户活跃度还是交叉销售其他金融服务的可能性都大大降低。

上图是通过 Pinwheel 在 ADP 系统完成 Direct Deposit 的示意。如果一个挑战者银行希望自己 50% 的用户能这样顺滑地设置储蓄，在没有 Pinwheel 的情况下，它将需要与数十家 HRIS 分别建立集成，这对于初创公司是几乎不可能完成的任务，对于成熟的挑战者银行也会消耗许多不必要的产研资源。

这类 Universal API 的优势在于客户的依赖度足够高，从第一天就需要它们，但这往往会限制它们客群的行业广泛度 —— 你可能已经注意到了，Plaid 和 Pinwheel 的几乎全部潜在客户都将是广泛意义上的 Fintech 客群，但由于潜在的高 LTV 和较低的 Churn 可能性，它们已经是 123 亿美元和 5 亿美元估值的公司。

2. 切入更大体量的客户群体

就像我们在拾象硅谷见闻中所说的，向企业客户销售是扩大 ARR 的终极道路。

然而中型（Mid-Market）和企业客户（Entreprise）对于引入新的软件供应商拥有许多期望，无缝的集成就是其中之一 —— 你必须在谈单子的过程中就构建好集成，他们没有机会等待你花数月时间集成它们的 ADP、Salesforce、Jira 等软件。对于大型企业客户，他们还会期待你拥有完整的安全性（SSO 和可供审计的 Log）。

Merge 和 WorkOS 是为解决这类问题而存在的典型，这类 Universal API 致力于帮助客户将产研精力配置在核心业务上，将无休止的集成路线图缩减为一次性的 Universal API 集成，助力这些公司从 SMB 开始走向中型和企业客户。

这帮助客户的工程师避开了这样的场景：在花数周构建完 Jira 的集成后，销售团队告诉他们需要继续与 Asana、Zendesk、Hive 构建集成来赢得新客户，他们接下来几个月的排期又将被占满，来处理难以阅读的文档和小心翼翼地避开各种坑。

Merge 已经为多种面向企业销售时常见的系统集成构建了 Universal API，而 WorkOS 则专注于汇集向大型企业客户销售所需要的一切，从 SSO（不同的公司可能在使用 Okta、PingOne、AzureAD 和市面上其他数十种产品） 、Directory 同步，到将 Log 打到客户的 SIEM（不管是 Datadog、Splunk 还是市面上其他的数十种产品）供他们审计和了解这个应用内发生的一切。

这类 Universal API 适配于各个行业的客户，只要他们希望迈向更大体量的客群。但不同于第一类，它们可能并不是客户在第一天就需要的，并且需要抓住新兴的客群和增量市场（那些还没有靠堆人和堆时间来解决企业集成问题的公司）。

3. 解锁数据辅助业务决策

这类场景下的 Universal API 与另类数据有一定的相似性，它们解锁的数据通常被用于辅助业务决策和提供分析建议。

以 Rutter、Codat 和 Ramp 的用例为例。Ramp 和 Brex 业务类似，为企业构建费控软件和发行信用卡。不同于科技初创公司 —— 科技初创公司亏损，但是银行账户上有融来的现金，通过 Plaid 就可以验证他们的财务可靠度 —— 大部分的电商公司都是强周转、低现金流水平的。Ramp 通过 Codat 和 Rutter 获得客户在会计以及电商平台上的数据来判断这类申请者的收入和盈利能力，并决定是否授信。

这类 Universal API 某种程度上也被局限于 Fintech 客户，是过去两年中 Plaid for &*% 热潮的代表者，市场对于他们解锁的这类数据能否与银行数据达到同等地位还持有一定的保留态度。

03.

为什么是现在？

我对这个领域的兴趣最初来自于 Ramp 对 Brex 的竞争，它为了授信更多客户和与中型企业的软件进行集成，而率先探索了 Rutter、Codat 和 Merge 这类公司。仅在 Fintech 的范围内，各类垂直的 Plaid 是最热门的创业方向，我在这里引用 Better Tomorrow Ventures 两位 GP 在 20 年的采访：

在 Fintech 之外，Merge 和 WorkOS 则代表着 Universal API 在整个软件行业的兴起。我将这种热潮出现的原因总结为：

1. Open API 本身的成熟

我们在 Zapier 的文章中系统介绍过 API，在此不再赘述。根据 Postman 做的 2022 年 State of API 报告，37000 多名受访者中有约 51% 表示，他们组织的一半以上开发工作都花在了 API 上 —— 相比之下，2020 年和 2021 年分别为 40% 和 40%。一些受访者强调 API 是现代软件的基石。值得注意的一点是 Webhook（前端不主动发送请求，完全由后端推送）走向了主流，它是 Universal API 的重要组成部分之一，保证了数据的实时和一致性。

2. 企业的数字化进程带来了软件的蔓延和分散

当企业不使用基于 Open API 的软件时，你只能通过 CSV 和文件发送来同步数据，当企业使用软件时，我们又有了分散和割裂的问题！Finch 的创始人 Jeremy Zhang 向 Sacra 透露：“如果你单看 HR 和 Payroll 市场，仅美国就有 6000 种不同的系统，其中前 10 名占据大约 55% 的份额。如果要覆盖这个市场 75%，一个 App 必须构建 40-50 个不同的连接器”。

3. 企业对于数据价值认知正在加深

就像我们在“为什么我们认为 Global SaaS 值得投资？”中提出的：

4. 面向企业客户（Entreprise）的销售被企业加速提上日程。

我从 WorkOS 的博客找到了有效的数据和知识来论证这一点：根据对 Openview PLG Mapping 里公司的抽样，从成立到向企业客户进行销售，2000 年代成立的 PLG 公司平均需要 8.5 年，而 2010 年代成立的 PLG 公司平均只需 4.1 年，大大提速。如果一家公司不能及时为企业集成做好准备，竞争对手会闯入并且抢走份额，我们看到了 Dropbox 和 Box、Microsoft Teams 和 Slack 等多组案例。

04.

重新思考 Universal

API 的 PMF

Universal API 是一个比较新的赛道，Plaid 是 10 年前创立的公司，而其他大部分公司都是近 5 年才成立，估值大都在 2-5 亿美元的区间。它们是否真的达成了 Product-Market-Fit？如果是的话，在什么条件下？这都是非常值得思考的问题。

鉴于 Universal API 某种程度上拥有 Marketplace 的属性，左右分别连接了数据源和客户的系统，我们可以从两侧分别来分析。

从数据的视角出发，客户使用 Universal API 而不是直接构建一对一集成的动力主要有几个：

· 数据本身就是被封锁、无法获取的

最典型的是 Plaid 早期面对的银行数据，以及各个领域中那些尚未融入 Open API 生态的软件们；

· 数据背后的系统是分散的

这意味着一对一集成的效率低下，每个集成背后的 webhook 对接和 API 文档阅读都是重复劳动，同时各个系统之间的数据还需要映射处理一道才能统一使用；

· 连接数据所使用的 API 是过时的，并且更新可能会影响连接

这意味着工程师在构建集成和进行测试的过程中会很痛苦，并且还需要占用一定的精力来维护已构建的集成。

尽管这个板块的公司宣称许多领域都值得 Universal API 进入，但是目前来看，银行和 HRIS 是少数完美契合这些点的类别，有许多古老的玩家还没有采纳 Open API，而像工单系统则完全是另一番景象 —— Jira 的 API 可并不难用，客户使用 Universal API 的唯一动力将是“分散”，这会大大削弱 Universal API 价值主张的厚度。

Carta Total Compensation 产品示意

在这个案例中，Carta 为完成集成（13 个主要的 HRIS 和 80 多个长尾的 HRIS）设置了明确的时间线，以赶上产品上线的预期时间。而这种时间线本身的出现则是因为这个领域的激烈竞争，Carta 需要保持不落后于竞争对手的速度，以防止对方先抢占客户的预算和心智。

同样的情况还发生在 Ramp 及 Brex 使用 Merge 来完成企业客户系统集成的案例中，它们的动力同样来源于竞争。因为我们认为客户处于激烈竞争的战场是多数 Universal API 获得其目前头部客户并榨取客观 ARR 的一个重要条件。这限制了这部分公司的 TAM —— 如果你不是核心业务的关键环节必备品，那你的客群就被局限在激烈竞争的新经济客群中。

05.

创业者指南：竞争力要素

在 Universal API 当前的景观中，我们挑选了 Plaid/Teller.io、WorkOS/Merge、Pinwheel/Finch 三组案例进行了深入研究，最终从这些案例身上总结出了 5 条对于 Universal API 类公司的关键竞争要素。

对于投资者而言，观察创业者如何思考这 5 个问题，将有助于我们判断其创业者精神和对行业的认知。

数据的类型和来源决定了可服务客群

对于这个领域的创业者而言，第一步是选择切入的数据，这很大程度上决定了业务和竞品的差异化程度。

以 WorkOS 和 Merge 为例，这组案例显示出了可服务客群在体量上的差异。客户可以都将它们使用到获取员工信息的场景上，但是 WorkOS 的数据来源于活动目录，而 Merge 的数据则来自 HRIS。鉴于活动目录维护的难度，这决定了 WorkOS 客户的使用对象将更偏向于有内部 IT 能力的大型企业，而 Merge 则更偏向中端市场。

这种差异进一步反映在了二者的定价上 ——在基础年费之上，Merge 采用用量定价，每条员工数据 0.2 美元，而 WorkOS 采用固定定价，每月每账户 49 美元，不限用量，因此一旦每月要获取的员工数据超过 245 条，使用 WorkOS 就更划算，那些服务大型企业的公司也更有动力使用 WorkOS。

Pinwheel 和 Finch 这组案例则是可服务客群在行业上差异的范本。二者都同样处理薪酬数据，但是 Pinwheel 的数据由员工个人授权，而 Finch 的数据由企业授权。这使得前者的客群被限制在 B2C Fintech 公司，使用个人的薪酬数据来进行 Direct Deposit 和授信；而 Finch 的客群则包括了 B2B 的 Fintech 和 SaaS 以及企业福利运营商。

这是竞争力要素中最重要的一个。创业者可以从几个角度思考数据对应客户群的竞争力，并做出适当的取舍：

· 客户群在体量上的大和小；

· 客户群在行业上的宽和窄；

· 客户群本身的利润情况和业务对该数据的依赖度。

形成差异化的核心价值主张

Universal API 天然带有一系列的价值主张，比如减少自行集成多个系统和维护多个已建立的集成等，这将带来工程师时间成本的缩减。但是在这个领域激烈的同质化竞争下，这类通用型价值主张的威力已经大大缩水，创业者需要尽早地形成自己差异化的核心价值主张，并将它融入 Go-To-Market 的行动中。

WorkOS 在这方面做得很好，它的 Slogan 是“Your App, Enterprise Ready”，很好地避开了 Universal API 的陈词滥调，并且直接显示出它与其目标客群的匹配。

Teller.io 所处的开放银行数据领域竞争更加激烈，但是在 MX、Yodlee、Plaid 等老牌厂商的重围之下，这家 20 年才完成种子轮融资的公司仍然获得了 Ramp、Brex、Pipe 等优质客户。这家公司做得好地方就在于其核心价值主张的塑造 —— 鉴于连接银行账户很容易断，Teller.io 使用了逆向工程破解银行的移动端 API，而不是屏幕抓取的技术路径，这让它在一些场景里更加稳定。这是 Teller.io 在与市场沟通的各类内容中一定会强调的方面。

同时让公司和工程师满意

使用 Universal API 对于任何一家成规模的公司都是一项投资 —— 通常 10 万以上的基础年费以及按用量的定价。

在公司决策层面，ROI 通常是重要的考量，Universal API 需要讲述的故事需要围绕两方面：在构建好集成或获取了新数据后，公司能赢得的新客户和收入；以及使用 Universal API 而节约的工程师成本。

同时，工程师们在挑选、使用和是否迁移 Universal API 的决策中有非常重要的作用，做得好的公司具备以下特点：

Merge 和 WorkOS 的客户服务都获得了许多好评，非常值得这个领域的其他公司学习。

Merge 拥有一个智能错误码系统，假设集成的连接由于某种原因失败（比如权限更改之类的），Merge 会弹一条报错，工程师可以选择接受该消息，将其发给客服，客服发给客户，这样客户的工程师也不用再去扒代码了。而 WorkOS 则会与每个客户有一个 Slack 频道，让 Developer Success Engineer 团队与客户的工程师进行直接交流，任何集成中的报错和疑问都可以通过一条 Slack 消息得到解决。

尽可能早地解决隐私顾虑

隐私和数据安全问题是每个 Universal API 都必须考虑和解决的。

最基础的功课是 SOC 2 Type II 合规认证，我们所研究的案例达到这一合规的平均时间是脱离匿名状态的 1.5 年内。此外，公司还值得在早期就开始组建该领域内的法务团队，以进行必要的内部审计和应对诉讼。

除了 SOC 2 之外，Universal API 还可以追求自己领域内的其他合规认证来增强跟客户的信任。Pinwheel 是薪酬类 API 里率先 FCRA（公平信用报告法）合规的公司，意味着它保证提供给客户的数据全面真实可信，并且承担回应消费者的工作，大大降低了它客户的信用风险。

在这些之上，我们认为 Plaid 构成了另一种范本 —— 通过塑造 B2B 软件的消费者品牌来创造信任。当消费者在连接银行账户时，Plaid 的 Logo 为他们天然带来一种安全可信的感觉。这源于 Plaid 的先发和规模优势、不做白标的坚持等原因，其他 Universal API 也值得长期为此努力。

Plaid Link 用户页面

从 Day One 就思考如何扩大 TAM

残酷的事实是：单纯的数据聚合并不是一门大生意。然而围绕着数据做生意却是最大的机会，比如拿到行为数据做广告生意的 Google 和 Facebook。

因此 Universal API 公司应该从第一天就思考如何扩大 TAM，特别是在 Plaid 树立了很好地范本：

· 横向拓展产品线，比如 Plaid 也做 KYC 和薪酬数据；

· 围绕数据进行丰富化，比如 Stripe 在 21 年 1 月也上线了 Deposit Switch 产品来帮助进行 Direct Deposit；

· 地域扩展；

· 基于数据切业务场景，比如 Plaid 正在尝试且被寄予厚望的无风险 ACH 支付；

· ……

我认为扩大 TAM 的思考与上文所说的“差异化的核心价值主张”紧密相关。

Teller.io 核心价值主张在于其对于 Plaid 等公司的补足效果，因此当它也想切入支付场景时，它没有选择这些公司正在尝试的 ACH，而是选择在 21 年 9 月上线了 Zelle 的实时支付 API。

WorkOS 也得益于其核心价值主张“Entreprise Ready”的独特性，其 TAM 很早就突破了 SSO 集成，它 在 20 年 9 月上线了 Magic Link 切入企业无密登录场景，22 年 7 月内测 Audit Log 切入日志审查这个环节，贯彻这个价值主张的同时极大丰富了产品线。

如果我和 Universal API 的创业者交流，“如何成为细分赛道第一名”和“扩大 TAM 的节奏将会是怎么样的”将是我最关心他答案的两个问题。

06.

投资人指南：建立研判框架

站在投资者视角，我们认为针对 Universal API 领域的投资研判有几个层次的思考：

SaaS 指标的达成 —— Universal API 公司基本都是标准的 SaaS 公司，其中最顶级的能在小于 1000 万美元 ARR 时做到 600% 左右的年增速、80% 的毛利率和 150% 以上的 NDR。

竞争力要素 —— 上文中的竞争力要素有助于判断三件事，即创始人的企业家精神和经营成熟度、核心价值主张的竞争力以及切入的市场大小。最理想的情况是创始人有意识地平衡了 3 个要素：客户群体量的区间（SMB、中端市场和大型企业），客户群行业的数量，以及客户对该 Universal API 所代表数据的依赖度。

公司的具体问题 —— 我观察到最常见的问题是 Universal API 产品路线图与核心大客户期望之间的落差，比如 Carta 使用 Finch 连接 HRIS，但是它也同时需要 ATS 系统的连接，而这并不在 Finch 原有的产品路线图上，因此 Carta 又引入了 Merge 作为潜在供应商。Universal API 本身的销售对象更偏向新经济客户，既要占住重要大客户的坑，又要持续榨取其 LTV，还要避免被其他 Universal API 卡位，如何平衡好这三者的关系也是这个领域非常值得思考的问题。目前来看，占住坑可能是第一位的，因为集成一旦上线，后续迁移成本就显得过高。

最后，M&A 可能将成为这类公司的重要退出路径。Google 2016 年以 6.5 亿美元收购 Apigee、Salesforce 65 亿美元收购 Mulesoft、Visa 53 亿美元对 Plaid 的收购邀约、Brex 以 5000 万美元收购成立仅 1 年的电商 Universal API Weaver……构建企业级集成平台本身是 Microsoft 和 Salesforce 等企业服务巨头的核心战略，它们将有很强的动力整合这个新兴的领域。而 Universal API 如果无法有效地扩大 TAM，也面临低上限的问题，被收购可能是更好的出路。因此对于这个领域而言，种子轮投资可能是广泛参与的最好方式。而少数最优质的标的（对于我来说，拥有独特价值主张的 WorkOS 和持续扩大 TAM 的 Plaid）才值得成长期投资者关注。

延伸阅读