API 与集成
两个入口，一把密钥。
两种进来的方式：用一句话交办 Octo，让它去编排；或者用工具调用直接驱动这个平台。两种都用同一把密钥，也都被同一套确认和风险机制包着，和后台里的那一套一样。
- production sk_live_7f2a····
- nightly sync sk_live_c418····
client = OpenAI(
base_url="https://api.omniocto.com/v1",
api_key=OMNIOCTO_KEY,
)或者，直接开口问
连管线的活儿也是一段对话。
密钥、webhook 和连接——都不用打开设置页面。
Gmailfrom:octo api
Octo密钥已创建：staging-runner — 只显示这一次——现在就复制走上午 10:12
OctoWebhook 已注册 — 带签名，你的接收端可以验证是我们发的上午 10:20
Octo确认：吊销密钥 ci-bot——YES 3517 — 所有在用它的东西都会停掉周五
Inbox密钥已创建：staging-runner
D我上午 10:10
我需要一个 API 密钥给预发布部署用，另外把事件推到我们的接口。
OOcto上午 10:12
密钥 staging-runner 已创建——它的值只出现在这封消息里。同一个密钥对 OpenAI 兼容接口和两个 MCP 服务器都有效。Webhook 已注册并带签名，你那边可以验证它确实来自我们。
Octo在线
现在有哪些密钥是启用的？
三个：staging-runner、ci-bot，还有一个三月建的叫“test”，之后一直没用过。
把三月那个删了
吊销密钥属于破坏性操作，所以需要一个验证码：回复 YES 3517。只能用一次，一天后失效。
YES 3517
已吊销。跟你在后台会看到的确认是同一套——API 也被这层包住了，不只是界面。
#omniocto4 位成员
DWDana下午 5:05
@Octo CRM 那个连接还正常吗？
OOctoAPP下午 5:05
处理中 🔧(正在执行connection_test_connection…)
正常。最后一次成功调用是 3 分钟前。另外两个连接也都没问题。 (edited)
✅ 21 条回复 · 最后回复于 40 分钟前
MRMarcus下午 5:24
故障期间丢掉的那些事件能重放吗？
邮件 octo@agent.omniocto.com · WhatsApp 1-MAN-ASK-OCTO · Slack #omniocto
- 和 Octo 聊天就能搭出智能体
- 把你想要的智能体描述出来，它就被搭好、部署好、接上——不管你是在后台里还是在邮件上，走的都是同一条流水线。
- 在邮件、WhatsApp、Slack 或后台里跟 Octo 说话
- 同一个助手的四道门，每道门背后是同样的确认机制，所以你用哪一道，只取决于你此刻的手在哪里。
- OpenAI 兼容的 API
- 在 OpenAI SDK 上换掉 base URL 和密钥，你现有的智能体就拿到了这个平台的工具。
- 两个 MCP 服务器
- 一个用来交办给 Octo、让它去编排，一个用来直接驱动平台自己的工具。按你想要的是一个结果还是一份控制权来挑。
- API 密钥
- 密钥在后台里签发和吊销，并带创建频率限制，所以一次被盗的会话没法一口气签出一大把。
- 签名 webhook
- 外发的 webhook 会被签名，所以你的接收方可以验证它确实来自我们，注册时还有 SSRF 防护。
- 可回放的实时事件流
- 一条实时的事件流，可以从你最后看到的那个 id 开始回放，所以一次断线不等于事件丢了。
- 幂等键
- 带同一个键重试的请求不会把这份活儿再干一遍，而用同一个键配不同的请求体会被拒绝，而不是被悄悄接受。
- 后台任务
- 耗时的活儿在后台跑，完成之后通过 webhook 送达，而不是把一个请求一直挂在那里。
- 多工作区
- 一个账号可以持有多个彼此隔离的工作区，代理商就是这样把客户分开来跑的。
- 七种模型可选，支持自带密钥
- 一份可选模型的白名单，也可以自带你自己的服务商密钥。
- 一切都可被机器读取
- 有一份 llms.txt、一份技能索引和一份 OpenAPI 描述，所以一个正在评估这个平台的智能体，不需要先有人替它总结一遍。
这些能力撑起了什么