Exchange Asset
An Exchange Asset in MuleSoft Anypoint Platform is a reusable artifact published to Anypoint Exchange (the integration content hub at the heart of MuleSoft) that other teams across the organization can discover, install, and reuse.
Definition
An Exchange Asset in MuleSoft Anypoint Platform is a reusable artifact published to Anypoint Exchange (the integration content hub at the heart of MuleSoft) that other teams across the organization can discover, install, and reuse. Asset types include API specifications (RAML or OpenAPI), API fragments, connectors, integration templates, examples, custom policies, and complete API products. The Exchange model is the foundation of MuleSoft's API-led connectivity vision: every reusable integration component is published to Exchange where it can be consumed by other projects, reducing duplication and accelerating delivery.
Inside Salesforce-integrated MuleSoft deployments, Exchange Assets bridge the gap between the broader MuleSoft asset library and the specific integration components Salesforce teams consume. A Salesforce admin building a Flow that calls an external API can browse Exchange for an existing connector or API specification rather than building from scratch. A MuleSoft developer publishing a new API publishes it to Exchange so future consumers can discover and reuse it. The combination of publish-and-discover patterns turns integration from a one-off engineering effort into a library-based composable practice.
The Exchange Asset model and its asset types
API specifications and fragments
API specifications (in RAML or OpenAPI format) are the most common Exchange Asset type. Each published spec describes a specific API's endpoints, request and response shapes, security model, and documentation. Consumers can browse the spec, generate client code in various languages, and mock the API for early development before the actual implementation is ready. API fragments are smaller reusable building blocks: shared data types, common security schemas, organization-wide patterns. Fragments enable consistency across multiple APIs without duplicating definitions; a change to a fragment propagates to every API that references it, ensuring uniform behavior across the integration estate.
Connectors and their ecosystem
MuleSoft connectors are pre-built integration components for specific systems (Salesforce, SAP, Workday, AWS, ServiceNow, hundreds of others). Each connector encapsulates the protocol, authentication, and data-format complexity of connecting to its target system, exposing a simple set of operations to MuleSoft flows. Exchange hosts both MuleSoft-built and partner-built connectors, with usage metrics and ratings to help consumers choose. For Salesforce-specific integrations, the Salesforce Connector is one of the most heavily used Exchange Assets, supporting bulk operations, real-time queries, change data capture subscriptions, and platform event publishing.
Integration templates
Integration templates are complete, working integration patterns published to Exchange that consumers can clone as starting points for their own implementations. Examples include Salesforce-to-SAP customer sync, multi-system order orchestration, account aggregation across CRM and ERP. Each template is a fully working MuleSoft application with connections to the relevant systems, mapping logic, error handling, and deployment configuration. Cloning a template and customizing it for the specific environment is significantly faster than building the same integration from scratch, and the templates encode best practices the consumer might not otherwise discover.
Custom policies and security
Anypoint Exchange also hosts custom policies: reusable security or governance rules that can be applied to APIs deployed through Anypoint API Manager. Examples include rate limiting policies, JWT validation policies, payload encryption policies, and custom logging policies. Publishing a custom policy to Exchange means every API in the organization can adopt the same policy with one configuration step, ensuring consistent security posture across the entire API estate. For regulated industries, custom policies are how compliance requirements (PCI tokenization, HIPAA audit logging) get applied uniformly without each API team reinventing the implementation.
Versioning and lifecycle
Every Exchange Asset is versioned. Publishers release new versions when the asset changes (a new API endpoint, a connector bug fix, an updated template). Consumers reference specific versions, which means a new version of an asset does not automatically affect existing consumers. Promoting a consumer to a new version is an explicit step coordinated with the consumer team. The lifecycle states (Draft, Published, Deprecated) signal asset health to consumers: Draft is unstable and not for production use, Published is stable, Deprecated signals that the asset will be retired and consumers should migrate. This lifecycle discipline keeps the asset library trustworthy as a foundation for production integrations.
Discovery, ratings, and governance
Exchange functions as the discovery layer for integration assets. Consumers search by keyword, browse by category, filter by asset type, and see usage metrics and consumer ratings. The discovery experience matches what developers expect from open-source registries (npm, Maven Central). Beyond discovery, Exchange supports governance through visibility controls: public assets are available to anyone with access to the Anypoint Platform, private assets are scoped to specific business groups or organizations, and partner assets are shared with specific external parties. Organizations with mature API programs use these visibility controls to balance reuse with appropriate access boundaries.
Salesforce-specific Exchange Assets
The Salesforce-MuleSoft integration story relies heavily on specific Exchange Assets. The Salesforce Connector handles inbound and outbound integrations with Salesforce orgs. The Salesforce Composite API connector handles bulk operations efficiently. Various Salesforce-specific templates demonstrate common patterns: Account-to-ERP sync, Lead enrichment from external data sources, Case-to-ticketing-system bridge. For customers running MuleSoft alongside Salesforce, these assets are the starting point for most integration work, and familiarity with them is essential to efficient implementation.
Asset governance at scale
As MuleSoft programs grow, the Exchange asset library can swell to hundreds or thousands of assets across many teams. Without governance, the library becomes noisy: duplicate APIs solving the same problem, deprecated assets that no one cleaned up, inconsistent naming and tagging that hurts discovery. Mature MuleSoft programs establish governance practices to keep the library useful: a center-of-excellence team that reviews new asset publications, naming and tagging standards documented in the API style guide, periodic audits that identify and retire unused assets, and consumer feedback loops that surface problems with specific assets. The governance work is most valuable in organizations with mature API programs operating across multiple business units; smaller deployments may not need formal governance. Regardless of scale, the principle holds: an Exchange library is only as valuable as its discoverability and trustworthiness, both of which depend on ongoing care from the publishing teams.
The role of Exchange in API-led connectivity
MuleSoft's API-led connectivity architecture organizes integrations into three tiers: System APIs that expose underlying systems, Process APIs that orchestrate business logic across multiple System APIs, and Experience APIs that serve specific consumer experiences. Exchange is the publication target for assets at every tier: System APIs published for downstream Process API consumption, Process APIs published for Experience API consumption, Experience APIs published for the consumer application development teams. The publish-and-consume model decouples the tiers, allowing each team to work independently while sharing a common asset catalog. Programs that adopt API-led connectivity fully report measurably faster delivery cycles than programs that build point-to-point integrations without the Exchange layer, because reuse compounds across the program over time. Each new integration finds existing assets to consume rather than starting from scratch, and the cumulative effect is a noticeably faster organization.
Publish and consume Exchange Assets
Working with Exchange Assets spans publishing assets your team creates and consuming assets others have published. The workflow below covers both sides, with the assumption that the team is working in the MuleSoft Anypoint Platform with an active Salesforce integration.
- Author the asset in the Anypoint Design Center or Studio
Create the API specification, integration template, or other asset in the appropriate MuleSoft tool: Design Center for API specs and fragments, Anypoint Studio for connectors and full integration applications, the Anypoint Platform console for custom policies. Develop and test the asset locally. Document its purpose, usage, and any prerequisites in the asset's README or description. Tag the asset with relevant categories and keywords for discovery.
- Publish to Exchange with the right visibility
From Design Center or Studio, click Publish to Exchange. Choose the target Business Group (internal scope), the version number, and the lifecycle state. Add a description, tags, and any required documentation. Click Publish. The asset appears in Exchange with its metadata and is now discoverable by other teams in the Business Group. For public assets, additional review may be required by the org's API governance team before broader visibility is granted.
- Discover assets to consume
From Exchange, search for assets relevant to the integration you are building. Filter by asset type (API, Template, Connector, Policy), by category, or by Business Group. Review the asset's documentation, version history, and usage metrics. Open the asset in the appropriate tool (Design Center for API specs, Studio for integration projects). The tool automatically downloads and incorporates the asset into your project, ready for use.
- Maintain and version your published assets
As your published assets evolve, release new versions with clear changelogs. Communicate breaking changes to consumers in advance. Deprecate old versions on a defined schedule once consumers have migrated. Monitor the asset's consumption metrics in Exchange to understand which versions are still in active use. Coordinate with consumer teams when retiring versions to avoid breaking their integrations. This ongoing lifecycle discipline is what makes the Exchange ecosystem trustworthy over time.
- Asset versions are immutable once published. New changes require a new version number; consumers explicitly migrate to it.
- Public assets are visible across the Anypoint Platform; private assets are scoped to specific Business Groups. Choose visibility carefully.
- Connectors built for older MuleSoft versions may not work with newer runtime versions. Confirm version compatibility before consuming.
- Asset deprecation should be communicated to consumers in advance. Sudden deprecation breaks active integrations.
- Internal Exchange assets are organization-specific. Cross-organization sharing requires explicit partner-asset visibility configuration.
Trust & references
Straight from the source - Salesforce's reference material on Exchange Asset.
- Anypoint ExchangeMuleSoft
- Publishing AssetsMuleSoft
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is an Exchange Asset?
Q2. What kinds of assets can be published?
Q3. Why is Exchange valuable?
Discussion
Loading discussion…