> For the complete documentation index, see [llms.txt](https://docs.visdom.virtuslab.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.visdom.virtuslab.com/visdom-orchestrator/user-guide/adapters-webhooks-and-schedules.md). # Adapters, webhooks and schedules Flows have to start from something other than a person clicking Run. The adapter layer is how the outside world reaches in, and how results reach back out. ## Inbound: webhook routes An **adapter installation** plus a **webhook route** gives an external system a URL to post to. The receiver validates the request, hands it to a dispatcher, and the dispatcher decides what it means: typically triggering a flow with parameters taken from the payload. The shipped flow templates declare which trigger kinds they accept (`manual`, `github_webhook`, `gitlab_webhook`), so a template is explicit about how it is allowed to start. Anything the dispatcher cannot process goes to a **dead-letter queue** rather than being dropped, and the queue is inspectable through its own routes. A webhook that silently did nothing is the worst failure mode in this class of system, so that queue is where to look first. ## Outbound: delivery with a circuit breaker Outbound delivery is driven by database notification rather than polling. Deliveries are recorded per attempt, retried on failure, and a **circuit breaker** opens after repeated failures against the same target so one dead endpoint does not consume the queue. Delivery records have their own admin surface, which is how you answer "the approval was raised, was anybody told". The generic webhook adapter is the one that works today. First-party Slack, SMTP, GitHub, GitLab and Jira adapters are **not built**. ## Schedules A cron scheduler fires targets on a schedule, and the target executor's `flow_trigger` target starts a flow the same way a webhook would. That is the mechanism behind anything periodic (a nightly triage, a weekly dependency sweep) without a separate scheduling system. The same target machinery also runs housekeeping, such as the daily memory purge. {% hint style="info" %} Everything in this layer is **workspace-scoped and auditable**: an installation, a route, a target and a delivery are all rows somebody created, and every one of them is a way into the system. When reviewing a deployment's security posture, the webhook routes deserve the same attention as the RBAC grants. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.visdom.virtuslab.com/visdom-orchestrator/user-guide/adapters-webhooks-and-schedules.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.