FlowCastle

List the applications this API key can access, with the caller role and the permissions it grants. Start here when using a personal API key (usr_...): every other tool needs an explicit applicationId, which this tool supplies. Read-only, takes no arguments. Returns an array of { id, name, role, permissions }; an empty array means the key is valid but belongs to no application yet.

Create a new application (workspace) owned by the caller. Requires a personal API key (usr_...) — application-scoped keys cannot create applications. Seeds default flows unless skipDefaultFlows is true. Creates persistent state and is NOT idempotent: calling it twice creates two applications. Returns the new application id, which you then pass as applicationId to the other tools.

Update application-level settings (name, active state, default language, incoming-message behavior). Requires the manage_settings permission in that application. Only the fields you pass are changed; omitted fields keep their current value, so the call is idempotent. Returns the updated application.

Crawl a website into a knowledge base so an AI_TOOL_ROUTER can answer from it. Creates a new base (named after the host) unless knowledgeBaseId is given. Honours robots.txt, skips junk and duplicate pages, keeps blog posts by default, and caps at maxPages. Returns at once with a job to poll via get_website_import. Prefer this over writing facts about a site you have not read.

Status of a website import started by import_website_knowledge or an import_website_into_knowledge_base action: stage, progress, counters, warnings and the pages that were not imported. Read-only. Poll until status is DONE, DONE_WITH_ERRORS or FAILED.

List the group/channel chats a telegram_mtproto userbot monitors. Read-only. The watched list is the single source of truth for which chats the userbot processes: messages from unlisted group/channel chats are dropped (fail closed) and their contacts never materialize; DMs always pass. botId may be omitted when the application has exactly one userbot.

Discover supported Telegram MTProto account operations, input schemas, permissions and limits. Requires manage_broadcasts. All current operations read public data; this catalog does not connect to Telegram. botId may be omitted when the application has exactly one userbot.

Submit one supported read operation on the connected telegram_mtproto account. Call list_telegram_operations for the input schema. Returns a requestId; poll get_telegram_operation until completed, error or timed_out. Requires manage_broadcasts. Nothing is sent, joined, marked as read, viewed or clicked. One operation per account, a 60-second deadline, shared read limits, and persistent flood cooldowns. Sponsored ads are cached for five minutes and represent one account’s targeting sample. Return

Read a Telegram operation status and result using its requestId and the same applicationId/botId used for submission. Requires manage_broadcasts for the owning application. Poll every two seconds. Results expire one hour after their last update. timed_out means no result arrived within 60 seconds; an offline or restarted runtime needs a new request. For throttling errors, respect error.retryAfterSeconds before submitting another operation.

Replace a telegram_mtproto userbot's watched-groups list — the chats it monitors. Requires the manage_settings permission. SET semantics: send the COMPLETE desired list every time (call list_watched_groups first and include existing entries you want to keep — omitting one removes it). Each entry needs a chatId (e.g. "-100…", for chats the account has joined) or a public username/t.me link; mode "joined" (default) processes a chat the account is in, "public_peek" (max 10, needs a username) polls

Import a telegram_mtproto userbot's existing chats as contacts — DM partners, groups, and channels — so everything the account already talks to becomes a valid send_message target without waiting for each chat to message first. Requires the manage_broadcasts permission. Reads the account's dialog list live (the userbot must be connected; large accounts can take up to a minute) and creates missing contacts; existing contacts are untouched, so the call is idempotent. Pass kinds to narrow the impor

Return a compact application, flow, sequence, operation, and bot summary — the cheapest way to orient in a workspace. Read-only, no side effects. Deliberately omits variables and full flow graphs: use get_variable_context for variables, get_flow_context for a flow's topology, and get_application_context when you need flows, bots, and variables together.

Search variable definitions by scope and keyword. Read-only. Returns { variables, total, returned, truncated } — compare returned against total to detect a cut-off result set and re-call with a higher limit. Values are withheld unless includeValues is true; variables marked secret stay redacted either way. Use the returned ids in `{{var|<id>}}` references.

Return the full application-level automation context in one read-only call: every flow (with folders), connected bots, variables, sequences, and operations. This is the broad orientation call — prefer get_workspace_summary when you only need names and counts, since this response grows with workspace size. Operation graphs are hidden flows and appear only in the operations list, never in flows.

Return a compact index of both installed and available marketplace modules, with each module's key, versions, description, actions, and triggers. Read-only. Start here when you need a capability the core action kinds do not cover; then call get_module_details for the exact input fields of one module, and install_module to add it. Returns a summary only — action input fields and setup requirements come from get_module_details.

Return everything needed to use one module: action input fields and their types, trigger configuration, manual setup fields (credentials an operator must fill in the dashboard), and references to already-installed actions. Read-only. Call get_module_catalog first to obtain moduleKey, and call this again after install_module to read the installed action references you need when drafting actions. An unknown moduleKey does not raise — the response carries an `error` string plus `availableModules` l

Install an exact marketplace module version into an application and create any missing installed-template actions. Requires the manage_automation permission. Call get_module_catalog first to select the module and version, then get_module_details after installation to inspect setup requirements and installed action references. Safe to re-run: installing a version that is already installed only fills in missing template actions rather than duplicating them. Modules with manual setup fields still n

Find every flow and block whose contents contain a keyword. Read-only. Searches message text and its translations, button labels and URLs, action names and configs, action input/output field paths and values, condition operands, trigger commands and payloads, custom-code files, and flow names and descriptions. A keyword matching a VARIABLE NAME also returns the blocks that reference that variable, which plain text search cannot do because blocks store variable ids, not names. Use this instead of

Return one flow's graph topology: its blocks, how they link, and a short summary per block. Read-only. Deliberately omits block data and action configs to stay cheap — once you know which block matters, call get_block_details for its full contents. This is the normal first step before editing an existing flow.

Return the complete contents of one block: block data, action configs, HTTP request bodies, custom-code files, triggers, menu payloads, and media paths. Read-only. This is the heaviest read in the API — call get_flow_context first to find the block you need rather than walking a flow block by block. Always read a block before updating it, since update_block replaces the fields you send.

Return the action-authoring contract that apply_actions batches are validated against. Read-only, needs no API key. Called with NO arguments it returns a compact INDEX: every creatable block type, action and topic with one line saying when you need it. Call it a second time naming only what the bot you are building actually uses — { blockTypes: ["AI_TOOL_ROUTER"], topics: ["knowledgeBases"] } — and you get those contracts in full, plus the batch contract, placeholder rules and the invariants tha

Return the flow-design rules that validation does NOT enforce: when to split a branch into its own flow, how navigation and menus must be wired, and worked examples. Read-only, takes no arguments, and needs no API key. Read this before any structural edit (new blocks, new branches, new flows) — a batch can pass validate_actions and still be badly structured, and these rules are what catch that.

Return the measured conversion funnels of the workspace's ENTRY flows over the last 30 days, busiest first: how many new contacts entered, which blocks they reached, the share who stop at each block, which buttons lead nowhere (pressed then silence), and how many recorded a goal. `dropoff` names the stage with the worst stop RATE and is null when no stage is bad enough to act on — a large `stopped` count on the first block of a flow is normal, because the whole cohort passes through it. An entry

Measure how NAMED flows are actually used over the last 30 days: how many contacts entered each one, where inside it they stop (per block, with the stop RATE), how many were answered by a human agent afterwards, and how many hit an error. Unlike get_funnel_analytics this works for ANY flow — including one reached from a menu button, a sequence, or an operator handoff, which the funnel cannot see at all. Pass the flow ids you want measured (from get_workspace_summary or the flow index). Read-only

Read what customers ANSWERED in this workspace's surveys. A survey is any flow marked isSurvey: its choice questions record which option each contact tapped, and its free-text questions store the reply the contact typed. Called with NO flowId it lists every survey flow with how many people it reached, how many answered, the response rate and how many wrote a free-text answer. Called with a flowId it returns that survey per question: every option with its share of the people who answered it, and

Search the library of reusable flow examples covering common business cases (lead capture, onboarding, payments, reminders). Read-only, needs no API key. Returns compact matches — id, title, summary, tags — with no flow body; pass an id to get_flow_example for the full example. Calling it with no arguments returns the top examples, and a query matching nothing returns an empty list rather than an error.

Return one reusable flow example by id, optionally with a complete action batch you can adapt and pass to apply_actions. Read-only, needs no API key. Call search_flow_examples first to find the id.

Dry-run validation of a proposed batch of flow-builder actions. Mutates nothing and is safe to repeat. OPTIONAL: apply_actions runs this exact validation itself and applies nothing when invalid, so calling validate_actions first is redundant — use it only to check a draft you do not intend to apply yet. Returns the same errors and warnings apply_actions would report. Note that passing validation does not mean the design is sound; structural rules live in get_design_guidelines.

Validate and apply a batch of flow-builder actions — the single write path for editing flows, blocks, variables, broadcasts, sequences, and folders. Call this directly; a separate validate_actions call beforehand is unnecessary. Broadcasts have no dedicated tool and are managed here: create_broadcast makes a DRAFT (it owns its flow via data.flowId — add the message blocks in the same batch, no separate create_flow), optionally with create_recurrence_schedule + attach_recurrence_to_broadcast for

Publish the workspace to its bots — the API equivalent of the dashboard's Deploy button. This is the step that makes edits live. apply_actions writes to the DRAFT graph. Until this runs the connected bots keep serving the previously published version, so a change that looks applied has no effect for real users. Deploy after a batch of edits (and after run_flow_autotest passes), not after every single action. Publishes the ACTIVE version to every active bot of the application; pass botIds to publ

Runs deterministic behavioural tests against flows that are ALREADY applied (compiles them to an AST and simulates a user). Call after apply_actions to verify a build; read `summary` and the failed checks, patch with apply_actions, re-run. Mutates nothing. The smoke layer runs on its own with no input: it walks every entry, taps every button, answers every input step, and reports crashes, dead buttons, unresolved placeholders, and values the bot failed to store. Pass `scenarios` to also replay s

Send a message to ONE contact right now, outside any flow. For reaching many contacts use a broadcast instead. Target the contact with contactId (globally unique — preferred), or with platformId (the platform-side id, e.g. the Telegram user id). platformId is NOT globally unique: it is unique only per bot, so the same Telegram user talking to two of your bots is two contacts sharing one platformId. Pass botId alongside it whenever the application has more than one bot; without botId the call suc

Run an EXISTING interactive flow for each listed contact right now, outside any trigger — as if each of them had just triggered it. Use it when the WHOLE message is the flow — its first block's text, media and buttons are what the recipient sees. To send your own custom text with buttons that run a flow on tap, prefer send_message with `buttons: [{ text, flowId }]`; it needs no wrapper flow. The flow starts at its start block for every recipient, and any `{{var|name}}` inside it resolves against

Read the message transcript: what users sent the bot and what the bot sent back, newest first. Source is the runtime's own message ledger, written by the bot as it handled each turn — inbound messages are recorded before any routing decision, so messages that matched no trigger are here too. Filter by contactId for one conversation, botId for one channel, direction for one side, actor_type for who wrote it (contact / bot / agent — a human replying from Live Chat or over mail), and startDate/endD

List and search contacts in the application, paginated, newest first. Read-only. Filters combine as AND; search matches name, username, email, phone, and platformId; `tags` / `tagIds` keep only contacts carrying at least one of those tags (UTM attribution tags are named "utm: <slug>" — discover them with list_contact_tags). `total` is the full match count, so `limit: 1` counts an audience cheaply. Returns compact contact summaries without variable values — use get_contact for one contact's varia

List the contact tags in use in the application (or one bot) with how many contacts carry each, most-used first. Read-only. This is the attribution view: UTM tags ("utm: <slug>", set by ?start=utm--<slug> deep links, one per ad or campaign) show how many contacts each source brought in; other tags are manual or flow-assigned segments. Only tags attached to at least one contact in scope appear. Pass a tag name to list_contacts `tags` to page through or count its contacts.

Return one contact's full profile plus every contact-variable value stored for them. Read-only. Values may hold personal data; variables of type SECRET are always redacted. Call list_contacts first to find the contactId.

Return one contact's engagement history: goals they achieved and buttons they clicked, newest first, plus all-time goal totals. Read-only. This is the per-contact companion to get_broadcast_analytics (which is aggregate). Clicks are inline/menu button presses inside the bot — typed replies, commands and website visits never appear. Goals and clicks are capped separately by `limit`; goalsTruncated/clicksTruncated say when older events exist. Call list_contacts first to find the contactId.

The reverse lookup: which contacts triggered one analytics event — achieved a goal (kind GOAL + goalKey), clicked a button (BUTTON_CLICK + blockId, optionally buttonId/buttonIndex), were sent a block (BLOCK_SENT + blockId), or received a broadcast (BROADCAST_DELIVERED + broadcastId). Read-only, paginated, ordered by each contact's most recent matching event. Runs as SQL over the event tables, so it is safe on large workspaces — prefer it over paging list_contacts and checking each one. Omitting

Create a contact manually — for imports or externally-sourced audiences; contacts who message a bot are created automatically. Requires the manage_broadcasts permission. platformId must be unique within the bot (duplicate fails with 409); botId may be omitted only when the application has exactly one bot. The variables map takes variable NAMES (or full folder paths when a name is ambiguous) — not ids — and unknown names fail with 422. NOT idempotent: retrying a success creates nothing new only b