Use this file to discover all available pages before exploring further.
Live example. A user types: “Create a segment of inactive enterprise users.”Candu resolves this to plan = enterprise, last_seen > 30 days, asks the user to confirm, then POSTs to /api/segments — 247 users matched.
Your product already has an API. Candu Actions gives your AI a structured, safe, auditable way to call it — on behalf of real users, inside your authentication boundary.
Those are the three things Candu does.Actions map to API endpoints in your product. You define the inputs they take, the roles that can trigger them, and whether they require user confirmation before executing. The AI can only call what you’ve explicitly defined.Workflows run inside your product using your users’ own credentials. Nothing routes through Candu’s servers at execution time. Your API only ever receives requests from the user’s browser.Logs record every run: the original request, the resolved inputs, the API response, any failures. When something breaks, you see exactly which layer failed and why.
Most teams start by wiring an LLM directly to a few API endpoints, writing some prompt logic, testing it, and shipping.Then the second workflow arrives, and the questions start: why did the AI send an invoice without confirmation, where’s the audit trail, and how does the next engineer figure out what the last one built?Governance, auditability, confirmation flows, reusable action definitions — these are solved problems. Building them from scratch doesn’t make your product more unique; it just delays the part that does. And each new workflow you add makes the system harder to debug and harder to change safely.No governance layer. Every action the AI can take is implicit, buried in prompts, not visible anywhere.No audit trail. When something goes wrong, you have no record of what the AI decided, what it sent, or what came back.No safe path for writes. Building confirmation UI, wiring it into every flow, keeping it consistent — that’s weeks of work that isn’t your product.Candu Actions is that layer, pre-built.
Not an agent framework. You don’t write orchestration code or manage LLM context. You define actions and ship flows.Not a chatbot builder. The goal is execution, not answers. A user says what they want and your product does it.Not middleware. Action execution runs inside your app. Your API only ever receives requests from your users’ own browsers.
Candu Actions is built for teams with structured workflows — things users want to do repeatedly, where the path is known but the inputs vary.Good fits: create a segment, send an invoice, configure an onboarding flow, update a project, launch a survey.Not a good fit: open-ended research, workflows with no API surface, single-action tools that don’t need orchestration.If your users know what they want but the UI gets in the way, Candu Actions is the right layer.