Mule SDK Development Best Practices

The purpose of this documentation is to provide users of the Mule SDK with best practices for building modules and connectors in a way that makes the best use of Mule runtime engine (Mule) functionality and is consistent with MuleSoft’s UX and quality guidelines.


This documentation uses these special terms:


A module that establishes connections to an external system. A connector is a module.

Large String

A String larger than 4 KB in size.


A plugin built through the Mule SDK that extends the functionality of Mule 4.

Mule language

The XML-based domain-specific language (DSL) used to write Mule applications and through which a module is used inside an operation.


The word "must" denotes a hard rule. This means that to be considered compliant with best practices, a module has to comply with all the practices described with this term.


This word "should" denotes a rule that, although recommended, could be skipped in certain cases and the module would still be compliant with best practices.

Target system

The resource that a connector accesses.


This refers not to the user of the Mule SDK (the one coding the module), but to the end user who consumes the module that a developer produces. All best practices are ultimately aimed at improving the end user’s experience.

MuleSoft Coding Practices

Using the SDK to create a new module or connector should not be approached as simply wrapping an API, library, or piece of functionality into a component that Mule can understand.

Instead, the problem should be approached as “extending a programming language called Mule.”

If you were to create a new library for the C programming language or your own Java framework, you would design library APIs, syntax, and semantics so that a C or Java developer consuming that library finds it consistent and compliant with all the rules and guidelines inherent to that ecosystem. Failing to do so results in unhappy consumers with unmet expectations for consistency and clarity.

The same applies to a custom Mule module or connector, which needs to be approached not as just creating a Mule bridge, but as an extension to the Mule language that provides additional functionality in a consistent, usable, and organic way.

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub