Built-In Module Library

Braidrun ships with 492 built-in modules. Each module is a packaged workflow with a typed input / output contract that other workflows reference via a sub_workflow step, without caring about the internal implementation.

General-purpose utilities (utility-* prefix, around 140)

utility-module-* prefix, covering business-agnostic building blocks like data processing, HTTP requests, search and scraping, text AI, and monitoring checks. Representative modules:

Delivery And Notifications

Reliable notification outlets at the tail of a workflow, mostly implemented as pure code steps that don't depend on an LLM, so a missing model credential can't break the notification path. Representative modules:

The remaining notification modules cover Discord, Feishu, WeCom, Microsoft Teams, Mattermost, and Rocket.Chat group bots, Mailgun / SendGrid email, and Bark, Pushover, and ServerChan push. There's also a Telegram file-delivery module that sends .md / .xlsx / .pdf / .csv reports along with a caption directly to a specified chat, with dedupe_key support to prevent duplicate sends on replay.

Financial analysis (module-* prefix, 10)

module-* prefix — a quant tool chain: quotes → technical indicators → portfolio analysis → backtesting. The quote modules need no API key (Tencent Finance / Yahoo Finance / CoinGecko data sources), and the indicator and backtesting modules are implemented with the standard library only.

The same series also includes modules for stock news, rule-based screening, options pricing, risk metrics, and market overviews, which can be chained into a complete pipeline from quotes to report.

Advertising and attribution (ads-* / attribution-* prefixes, around 12)

These modules come from real ad-operations work and cover report pulls and attribution data for the major ad platforms. Grouped by purpose:

• ASA report pulls：Four dimensions — campaigns / keywords / adgroups / searchterms — smoothing over the API's field-naming differences automatically.
• ASA entity lists：Bulk pulls of campaigns, ad groups, keywords, and negative keywords.
• Google Ads tools：Run GAQL queries and return structured results, plus campaign-performance reports and accessible-account discovery.
• App revenue pulls：Fetch revenue and subscription data by time window.
• Time-window Resolution：Convert a look-back day count plus a timezone into standardized start and end dates, so "yesterday / last week" means exactly the same thing across a batch of reports.
• Report Assembly：Multi-sheet Excel construction and Markdown report-template rendering.
• Multi-app batch processing：Run the same sub-flow once per app across a batch and merge the results.
• Quality review loop：A standardized quality gate: generate → score → retry if below bar → exit once it passes.

Business scenarios (business-* prefix, around 150)

The largest group: ready-to-run business actions around a specific external system — exception sweeps, operations briefings, data syncs. They are named business-module-<service>-<purpose>, so searching by service name is the quickest way to find one.

Connection health checks (integration-* prefix, around 70)

Liveness modules that map one-to-one onto the connectors, used to confirm whether a given third-party authorization currently works. Handy as a pre-check at the start of a long flow, or on a schedule of their own to sweep every authorization.

See the connector overview

Module Contract

Each module declares a contract: inputs are typed (string / number / boolean / enum / path / json) and can be annotated with required, a default value, enum values, and a numeric range; outputs declare a name, type, and source variable; and the contract has a contract_version that's independent of the workflow's implementation version.

module:
  enabled: true
  display_name: Web Search
  contract_version: 1.0.0
  inputs:
    - {name: query, type: string, required: true}
    - {name: provider, type: enum, default: duckduckgo,
       allowed_values: [duckduckgo, serper]}
    - {name: max_results, type: number, default: "10", min: 1, max: 100}
  outputs:
    - {name: results_json, type: string, source: "{{var:results_json}}"}
    - {name: result_count, type: number, source: "{{var:result_count}}"}

When you change a contract, the platform compares the new one against the old: non-breaking changes (like adding an optional input) pass straight through; breaking changes (which affect existing callers) are rejected by default and require explicit confirmation, with a suggested new contract version number. Contracts also support a deprecated marker plus migration notes to prompt callers to switch to a replacement module.

Declare third-party service dependencies

Modules that require external services do not input the key as an ordinary string, but name which service it depends on in the contract:

module:
  inputs:
    - {name: stripe_api_key, type: "credential:stripe", required: true}
    - {name: since, type: string, required: false}

This type of input is taken over by the platform: connection variables are automatically registered and wired when dragged into the workflow, the original input editor no longer appears, and the referrer does not need to know what the token of the service looks like.

View full description of third-party authorizations

Referencing In A Workflow

Reference by module id via a sub_workflow step. The values in inputs are all strings (numbers are written as "10" too) and support variable templates; outputs maps the module's outputs back to the parent workflow's variables for later steps to use directly.

workflow:
  - step: fetch_metrics
    sub_workflow:
      name: utility-module-http-request
      version_strategy: latest
      inputs:
        url: "https://api.example.com/v1/metrics"
        method: GET
      outputs:
        status_code: fetch_status
        response_body: metrics_json

  - step: notify
    sub_workflow:
      name: utility-module-slack-webhook
      inputs:
        webhook_url: "{{var:slack_webhook_url}}"
        text: "Metrics updated: {{var:metrics_json}}"
      outputs:
        send_status: notify_status
    depends_on:
      - fetch_metrics
    retry:
      max_attempts: 2
      backoff: exponential

• version_strategy The default is latest; when a fixed version is required, write version_strategy: pinned and fill in pinned_version at the same time. Just writing the version number or just changing the policy are incomplete. The range policy is currently not supported for running.
• A reference pointing at a module operates in contract mode, validating inputs / outputs against the contract; if the module is demoted back to an ordinary workflow, the reference degrades to lenient mode and is no longer validated automatically.
• Step modifiers like retry, condition, and depends_on work on sub_workflow steps as usual.

Custom Module

Any workflow can be promoted to a module: in the editor's workflow settings panel, find the "Module contract" section, fill in the display name, description, inputs / outputs, and contract version, and click "Save module contract." It then appears in the module library, and other workflows can reference it via sub_workflow.

When you revoke module status (demote), the platform first runs a reverse-dependency check: if any parent workflow still references the module, it lists the specific reference locations and blocks the operation, to avoid quietly breaking someone else's flow.

Like templates, modules can be published to the marketplace with a version number, and dependencies are resolved automatically on install.