Your Mule app,
type-checked.

Static analysis for MuleSoft 4. Types from your API specs, database schemas and Salesforce org are followed through every flow, DataWeave script and connector, so mistakes show up in your terminal or CI, not in production.

Get started See what it catches

src/main/resources/api/orders.raml

types:
  Order:
    properties:
      id: string
      customerId: string
      total: number
/orders:
  post:
    body: Orderrequest
    responses:
      201: { body: Order }response

src/main/mule/api.xml

<flow name="post:\orders:application\json:api-config">
payload: Order, the request body
  <logger message="#['Order for ' ++ payload.custmerId]"/>
  <ee:transform>
    <ee:message>
      <ee:set-payload><![CDATA[%dw 2.0
output application/json
---
{ id: uuid(), customerId: payload.customerId }]]></ee:set-payload>
no total, but the 201 response is Order
    </ee:message>
  </ee:transform>
</flow>

request

api.xml:15 unknown-fieldWARNING

Field custmerId is not declared of Order (known: id, customerId, total). Did you mean customerId?

response

api.xml:16 response-type-mismatchERROR

POST /orders returns a payload that does not match the 201 response 'Order': $.total: missing required field.

Valid XML.
Still broken at runtime.

Each example is real analyzer output for a small orders project with a RAML spec, a SQL schema, a Salesforce describe and a sibling customers API.

Enable JavaScript to browse examples, or see the rule list.

Follow the event.
Find the fault.

Muleflow builds a model of your whole application and tracks what each processor does to the event, across files and flow references.

Every path matters.

Variables set on only some branches, broken flow references, error read outside a handler, shadowed or empty handlers, and config Mule refuses to deploy.

Flows & sub-flowsError handlingDeploy checks

Make the shape fit.

Types inferred from specs, queries and DataWeave flow into every selector. Unknown fields, bad function arguments, missing imports and responses that break the contract.

DataWeaveRAML / OpenAPIStudio metadata

Check the connections.

SQL and SOQL against your schema and org metadata, connector operations from their jars, HTTP contracts of sibling APIs, and properties per environment.

DatabaseSalesforceAny connectorProperties

Unknown and dynamic values stay unknown, so findings stay trustworthy. All rules

Your terminal.
Your pipeline.

Readable text for a quick check. A self-contained HTML report with filters and search. SARIF for code scanning. JSON for your own tools.

Commit a baseline to report only new findings, and pick the severity that fails the build.

CI reporting docs

uv run muleflow-analyzer ./orders-api

src/main/mule/api.xml:44: warning [possibly-undefined-variable] Variable 'approval' may not be set on every path reaching this point (guard with 'default' or set it before branching). processor: logger flow: audit-order call path: api-main -> post:\orders:application\json:api-config (src/main/mule/api.xml:9) -> audit-order (src/main/mule/api.xml:28) 16 findings: 11 errors, 5 warnings, 0 infos

One command away.

Clone the repo, sync with uv, and point the analyzer at a Mule project or a folder of projects. Requires Python 3.15+ and uv.

Get the source

git clone
                  https://github.com/f-schnabel/muleflow-analyzer.git
cd
                  muleflow-analyzer

Sync dependenciesuv sync --locked

Analyze a projectuv run muleflow-analyzer path/to/mule-project

All CLI options

Questions

Does it need a running Mule runtime?

No. Muleflow analyzes project files without starting Mule or opening Studio. Connector jars from your Maven repository, API specs, database schemas and Salesforce metadata enrich the checks when available; Salesforce metadata can come from offline describes or an authenticated org.

Can I analyze several projects together?

Yes. Point at a folder containing Mule projects. Each project is analyzed with its own properties and specs, then findings are combined. Sibling API projects supply HTTP contracts for outgoing requests.

How accurate are the findings?

Predictions are checked against a real Mule runtime with a conformance harness. Dynamic expressions and missing metadata stay unknown instead of producing guesses.

Will it catch every runtime error?

No. Static analysis has limits, especially for dynamic expressions and unavailable metadata. Use it alongside runtime tests; the README lists supported behavior and known limitations.

Your Mule app,type-checked.

Valid XML.Still broken at runtime.

Follow the event.Find the fault.