How ORQO Connects
ORQO is not a closed system. Workflows receive input from the outside world and push results back out. This page is the map -- it shows every path data can take into and out of the platform, with links to the detail pages.
┌─────────────────────────┐
Webhooks ──────────►│ │──────────► Channel replies
Channel messages ──►│ │──────────► Tool calls (APIs)
API calls ─────────►│ ORQO Workflows │──────────► Artifacts (PDFs)
Cron schedules ────►│ │──────────► Shared memory
Workflow triggers ─►│ │──────────► Triggered workflows
Outcome routing ──► │ │
└─────────────────────────┘
Inbound: World to Workflows
These are the ways external events start or feed into workflow execution.
| Path | How it works | Auth | Detail page |
|---|---|---|---|
| Webhook triggers | Any HTTP POST to a unique URL starts a workflow run. The request body becomes the workflow's initial input. | Token in URL | Webhooks / Triggers reference |
| Channel messages | Messages from Slack, Telegram, WhatsApp, or Email arrive via App webhooks, are verified and normalized, then routed based on the App's setting — either to Doorkeeper for conversational handling or to workflow triggers for direct event processing. See Inbound routing below. | Contact-based or trigger-matched | Apps & Channels |
| API trigger | POST /api/v1/trigger with an API token starts any workflow by ID. For programmatic, authenticated use from CI/CD pipelines, monitoring systems, or your own code. | Bearer token | API |
| Cron schedules | Time-based triggers fire workflows on a recurring schedule. Natural language ("every weekday at 9am") or raw cron expressions, with timezone support. | None (internal) | Schedule Workflows / Triggers reference |
| Agent-initiated | A running agent triggers another workflow by name. The calling agent blocks until the triggered workflow completes and returns results. Same project only. | Internal | Workflow Triggering |
| Outcome routing | A stage outcome deterministically routes to a different workflow (not just a different stage). No LLM decision -- pure configuration. Pairs naturally with human approval gates. | Internal | Outcomes & Routing / Workflow Triggering |
Inbound routing: Doorkeeper or triggers
Every App that receives events has a Route to Doorkeeper checkbox in its drawer (Settings → Integrations → open the App). This single toggle decides how inbound events are handled.
┌─► Doorkeeper ──► responds, delegates, manages documents
Slack ─────┐ │ (Route to Doorkeeper: ON)
Telegram ──┤ inbound event │
WhatsApp ──┼──────────────────► ┤
Email ─────┤ │
Webhook ───┘ └─► App-event triggers ──► matching workflows start
(Route to Doorkeeper: OFF)
Route to Doorkeeper: ON (default) — conversational mode.
- Messages flow into Doorkeeper, which decides whether to reply directly, delegate to a workflow, or manage projects and documents.
- The sender must be a registered Contact in your organization. Events from unknown senders are ignored. This is the right mode for Slack DMs, email replies, Telegram chats — anything where a human is on the other end.
Route to Doorkeeper: OFF — event-trigger mode.
- Doorkeeper is bypassed entirely. Inbound events are matched against app-event triggers defined on workflows in your organization. A matching trigger fires the workflow directly.
- No Contact is required — this mode is designed for machine-to-machine event streams (a GitHub App sending repo events, a monitoring service forwarding alerts, a custom webhook adapter pushing business events).
- When the toggle is off, the App drawer reminds you: "Doorkeeper routing is off. Inbound events will be matched against workflow triggers. Add app-event triggers on your workflows to process incoming events."
To create the triggers that match in event-trigger mode, see App-Event Triggers.
Webhook triggers (a workflow's own unique URL) and the API always start workflows directly — they never go through Doorkeeper regardless of any App setting.
Outbound: Workflows to World
These are the ways workflow execution produces effects in the outside world.
| Path | How it works | Detail page |
|---|---|---|
| Channel replies | Doorkeeper and agents send messages back through the originating App -- Slack threads, WhatsApp chats, Telegram conversations, or email. Delivery is handled by the App's adapter. | Apps & Channels / Doorkeeper |
| Tool calls | Agents call tools provided by MCP servers, App-provided tools, or Runtimes. This is how workflows query databases, call APIs, execute code, push to GitHub, post to Reddit, and interact with any external service. | Tools / MCP Servers |
| Artifacts | Agents produce structured deliverables -- reports, dashboards, briefs, memos -- as interactive HTML with PDF export. Artifacts can be saved to the project's document library and classified into the knowledge graph. | Artifacts |
| Shared memory | Agents share results with the stage data store. Downstream stages and triggered workflows read this data to continue the work. | Assignments |
| Triggered workflows | A workflow's output can start another workflow (see Inbound above). Results flow back to the calling agent or are stored in shared memory for downstream use. | Workflow Triggering |
| Public Chatbot | Projects with Long-Term Memory can publish a chatbot widget that answers questions from the project's knowledge graph. Embeddable on any website, no login required. | Public Chatbot |
Choosing an Integration Path
| You want to... | Use |
|---|---|
| Let external services fire workflows on events (GitHub push, Zapier trigger, CI/CD) | Webhook trigger |
| Let users interact with your AI via messaging platforms | Apps & Channels + Doorkeeper |
| Trigger workflows from your own code | API |
| Run workflows on a recurring schedule | Cron triggers |
| Compose modular workflows that call each other | Workflow Triggering |
| Give agents access to external APIs and services | MCP Servers / Tools |
| Produce polished documents from workflow output | Artifacts |
| Publish a knowledge-powered chatbot on your website | Public Chatbot |