用途：设计新的 Clay 集成，并在不同规模与场景下比较并选择架构方案。Clay 为托管 SaaS，架构决策围绕如何送入数据（webhook）、如何取出丰富后的数据（HTTP API 列、CRM 同步或 CSV 导出）以及如何编排流程。
三种模式： 一、直接集成（简单）：适合小团队、每天少于 1K 次丰富、临时使用。通过 webhook 同步发送线索，结果靠 CRM 原生动作列或手动 CSV 导出。优点是零基础设施、约 5 分钟设置、适用于所有套餐；缺点是无重试、无法程序化获取丰富数据、仅手动导出。 二、Webhook 入站、HTTP API 出站（标准）：适合成长型团队、每天 1K 至 10K 次丰富、需 CRM 集成。应用经 webhook 送线索，Clay 用 HTTP API 列回调你的 webhook 处理并路由到 CRM、外联或数据库。优点是全自动、可程序化获取数据、路由灵活；缺点是需要 Growth 及以上套餐（HTTP API 列）、需公网 HTTPS 端点。 三、基于队列的流水线（规模）：适合企业、每天 10K+ 次丰富、多数据源。Web 表单、CRM 事件、CSV 导入进入 BullMQ 队列，worker 限速发送到 Clay，失败进 DLQ，出站经带熔断的处理程序分发。优点是任意量级、自动重试、DLQ、多源；缺点是需要 Redis 队列基础设施、运维更复杂。
决策依据包括量级（<1K/天、1K-10K/天、10K+/天）、所需套餐、基础设施、重试、数据访问、CRM 同步、复杂度与实施时间。
错误处理：需要实时数据却用直接模式应升级；队列积压应降低并发并加延迟；HTTP API 列超时应立即返回 200 并异步处理；额度耗尽应加带额度上限的熔断器。
限制：资料未提供各套餐的具体价格与额度、Clay 端点细节及完整官方文档内容。