MuleSoft Publishing Assets to Exchange

Publishing an asset to Anypoint Exchange makes it available to your entire organization. Other teams find it, understand it through the documentation you provide, and reuse it. Good publishing practices — clear descriptions, versioning, examples — determine whether your assets get adopted or ignored.

Publishing an API Specification from Design Center

After designing your API in Design Center, publish it to Exchange with one click. The API specification becomes a searchable, documented asset with an auto-generated interactive console.

1. Open your API specification in Design Center
2. Click Publish to Exchange in the top-right menu
3. Fill in the publishing form:
   • Name: Orders API
   • Asset Type: REST API
   • Version: 1.0.0
   • Tags: orders, commerce, v1
   • Status: Stable (or Development for WIP)
4. Click Publish

Publishing a Mule Application as a Template

To publish a Mule project as a template so teammates can download and reuse it, use the Anypoint Studio Exchange publisher or the Maven plugin.

Publishing via pom.xml

In pom.xml, add the Exchange publisher plugin:

<plugin>
  <groupId>org.mule.tools.maven</groupId>
  <artifactId>exchange-mule-maven-plugin</artifactId>
  <version>0.0.17</version>
  <executions>
    <execution>
      <id>validate</id>
      <phase>deploy</phase>
      <goals><goal>deploy</goal></goals>
    </execution>
  </executions>
</plugin>

Run: mvn deploy

This packages the project and publishes it to Exchange 
as a Mule Application or Template asset.

Publishing a Custom Connector

If your organization built a custom connector for an internal system, publish it to Exchange so other teams can use it in their projects without building their own.

1. Build the connector using the MuleSoft SDK (Java-based)
2. Package it with mvn clean package
3. Publish with mvn deploy using the Exchange publisher plugin
4. Other teams add it to their projects by searching Exchange in the Mule Palette

Publishing RAML Fragments

Fragments published to Exchange are referenceable from any API spec in your organization. Use the Design Center to publish fragments, or publish via the Exchange API.

Fragment Publishing Workflow

1. Create fragment in Design Center:
   File: common-types.raml
   #%RAML 1.0 DataType
   type: object
   properties:
     correlationId: string
     timestamp:     datetime

2. Publish to Exchange:
   Name:    Common API Types
   Type:    RAML Fragment - Data Type
   Version: 1.2.0

3. Other RAML specs import it:
   uses:
     types: exchange://myorg/common-api-types/1.2.0/common-types.raml
   
   /orders:
     post:
       body:
         properties:
           order: Order
           metadata: types.CommonMetadata

Asset Documentation Best Practices

Exchange displays the content of your README file as the asset's documentation page. Write a thorough README to help users understand and use your asset quickly.

Good README Structure

# Orders API

## Overview
This API manages customer orders for the estudy247 e-commerce platform.
It follows the API-Led Connectivity pattern as a Process API.

## Authentication
Client ID Enforcement. Register your application in Anypoint Exchange
to obtain your client_id and client_secret.

## Base URL
https://api.estudy247.com/orders/v1

## Endpoints
| Method | Path            | Description          |
|--------|-----------------|----------------------|
| GET    | /orders         | List all orders      |
| POST   | /orders         | Create a new order   |
| GET    | /orders/{id}    | Get order by ID      |
| DELETE | /orders/{id}    | Cancel an order      |

## Request Example
POST /orders
{ "customerId": "CUST-001", "items": [...], "total": 150.00 }

## Response Codes
200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 404 Not Found

## Contact
Integration Team: integrations@mycompany.com
Slack: #api-support

Asset Lifecycle Status

Set the correct lifecycle status when publishing so consumers know how stable the asset is.

Status Meanings

Development  → Work in progress, may change frequently. Do not use in production.
Stable       → Tested and production-ready. Follows semantic versioning.
Deprecated   → Being phased out. Consumers should migrate to the new version.
Deleted      → Removed from Exchange. Existing pom.xml references break.

Semantic Versioning for Exchange Assets

Use semantic versioning (major.minor.patch) for all Exchange assets:

• Patch (1.0.1): Bug fix, no API changes
• Minor (1.1.0): New feature added, backward compatible
• Major (2.0.0): Breaking change — existing clients may stop working

Always increment the version before publishing an update. Never overwrite an existing stable version — consumers depending on that version would get unexpected changes.