# mulesoft Connector Builder - Full Documentation

<!-- document id=f62770df627aaa20dbe5b12ac0cb504348871b002addc70f9d76d18d1c090910 url=/mulesoft/current/en-us/connector-builder/base-connectivity.md -->

---
product: Connector Builder
version: master
---

# Base Connectivity

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Learn how to generate the base connectivity for your connector. Base connectivity is the foundation
of your connector and it defines the basic structure of your connector.

The base connectivity includes:

- `{projectname}-connectivity-model`

  This is the canonical connectivity model (CCM). This package contains the code that directly
  reflects the structure of the API specification from which a project is generated. This is written
  in LinkWeave, and is the base from which all connectors will be built.

- `{projectname}-{platformname}-connector-model`

  This package represents a platform-specific connector (Anypoint Platform or Salesforce Flow) which
  takes the connectivity model as a base and adds customizations and transformations to address
  platform limitations or enhance the user experience. It also contains the `Connector.dwl` file,
  which defines the connector.

You can generate base connectivity either from an API specification (OAS 3.0), AI assistance
(available when using Cursor), or MCP tools (available when using Cursor).

## Generate Base Connectivity from an API Specification

1.  Open the Connector Builder extension in VS Code or Cursor.

2.  Select **New Project**.

3.  Enter the required information in **Project Details**.

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Description</th></tr></thead><tbody><tr><td><p><strong>Connector Name</strong></p></td><td><p>Enter a name for your connector. The name must be lowercase, alphanumeric, and contain no spaces. The name can’t exceed 20 characters.</p></td></tr><tr><td><p><strong>Connector Description</strong></p></td><td><p>Enter a description for your connector.</p></td></tr></tbody></table>

4.  Optionally, expand **Advanced Settings** to override the Maven group ID, base package, and
    connector vendor defaults.

5.  Optionally, click **Select Icon** to upload an icon for your project.

6.  In **Connectivity Platforms**, select **Anypoint Platform**, **Salesforce Flow**, or both.

7.  Click **Next**.

8.  Click **Select API Spec** and then select the API specification (OAS 3.0) to upload to create
    your connector.

9.  Click **Open Spec**.

10. Select the API endpoints that you want your project to include.

11. Click **Next**.

12. Select the folder where your project is contained. A subfolder is automatically created within
    this folder.

13. Click **Select Containing Folder**. Your project is created, and VS Code opens the newly created
    project.

## Generate Base Connectivity with AI Assistance (Cursor)

1.  Open the Connector Builder extension in Cursor.

2.  Select **Settings** and ensure **Enable Ai Assisted Workflows** is enabled.

3.  Select **New Project**.

4.  Enter the required information in **Project Details**.

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Description</th></tr></thead><tbody><tr><td><p><strong>Connector Name</strong></p></td><td><p>Enter a name for your connector. The name must be lowercase, alphanumeric, and contain no spaces. The name can’t exceed 20 characters.</p></td></tr><tr><td><p><strong>Connector Description</strong></p></td><td><p>Enter a description for your connector.</p></td></tr></tbody></table>

5.  Optionally, expand **Advanced Settings** to override the Maven group ID, base package, and
    connector vendor defaults.

6.  Optionally, click **Select Icon** to upload an icon for your project.

7.  In **Connectivity Platforms**, select **Anypoint Platform**, **Salesforce Flow**, or both.

8.  Click **Next**.

9.  In **Don’t have an API spec?**, click **Generate with AI**.

10. Enter the required information.

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Description</th></tr></thead><tbody><tr><td><p><strong>Name of SaaS Platform</strong></p></td><td><p>Enter the name of the SaaS platform you want to create a connector for. The name can’t exceed 20 characters.</p></td></tr><tr><td><p><strong>Top Use Cases</strong></p></td><td><p>Enter the top use cases for the connector, from most important to least important. Use natural language to describe the use cases. Keep the use cases succinct, such as <code>List invoices</code>, <code>Create an invoice</code>, or <code>Create an order</code>. If you want full CRUD (Create, Read, Update, Delete) behavior, you must explicitly mention each one.</p></td></tr><tr><td><p><strong>Links to API Documentation</strong></p></td><td><p>Enter the URLs of the official API documentation or reference sources for the connector.</p></td></tr><tr><td><p><strong>Project Folder</strong></p></td><td><p>Select the root directory of your project. All project files will be created here (a subfolder will not be created in this case).</p></td></tr></tbody></table>

11. Click **Copy Prompt**. This copies a prepared prompt to your clipboard, which you can manually
    paste into the Cursor chat window.

12. Open the Cursor chat window (if not already open) and paste the copied prompt.

13. Optionally (but recommended), copy your provided URLs from the `apiDocs` section of the prompt
    and paste them just before the final line. Be sure to add an `@` symbol in front of each URL so
    that Cursor recognizes them as resources. When done correctly, the URLs are highlighted in blue.

14. Ensure you’re in Agent mode. You can optionally choose which LLM that Cursor sends your prompt
    to.

    > [!NOTE] Connector Builder has been tested with `claude-sonnet-4`. Each model performs
    > differently and might yield different results.

15. Click **Send**.

16. Wait for the agent to complete its work. AI by nature is non-deterministic, so running the same
    prompt multiple times might yield different results each time. The expected outcome is:

    - `{projectroot}/discovery/discovery.json` is generated, capturing the LLM’s recommendations for
      implementing the requested use cases.

    - `{projectroot}/discovery/{saasname}.yaml` is created, containing the discovered endpoints,
      required schemas, and related details.

    - The extension detects the new API specification and automatically generates a project based on
      it. This process may take several seconds.

    - Cursor closes and reopens in the root directory of the newly created project.

## Generate Base Connectivity with MCP Tools (Cursor)

1.  Open the Connector Builder extension in Cursor.

2.  Select **Settings** and ensure **Enable Mcp Tools** is enabled.

3.  Open the Cursor chat window (if not already open).

4.  Ask the agent to create a connector. For example, enter `Create an Eventbrite connector`. This
    calls the `uc_create_connector_workflow` MCP tool, which plans an end-to-end connector build and
    returns a numbered workflow plan for sequential execution.

5.  Enter the required inputs when prompted.

6.  Confirm your inputs. This calls the `uc_manage_api_spec` MCP tool, which researches the API and
    generates the API specification (OAS 3.0). The same tool also supports `type='research'` to
    produce only an `api-reference.md` research artifact, and `type='validate'` to validate an
    existing OpenAPI spec against a live API.

7.  Enter the required inputs when prompted. Note that the connector name can’t exceed 20
    characters.

8.  Confirm your inputs. Review the API specification and make any needed changes. Then, instruct
    the agent to continue.

9.  Enter the required inputs when prompted.

10. Confirm your inputs. This calls the `uc_generate_connector` MCP tool, which generates the
    connector layers. The tool supports multi-phase generation including `ccm` (Canonical
    Connectivity Model), `anypoint` (Anypoint connector module), and `flow` (Flow connector module).
    Your connector is now created.

For more information, see
[MuleSoft DX MCP Server Tool Reference](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools).

<!-- document id=b02386b36965f6fb28b3f10e00ce2407ecfb3038c24c909a39ccf24b305970bf url=/mulesoft/current/en-us/connector-builder/best-practices.md -->

---
product: Connector Builder
version: master
---

# Best Practices for Connector Builder

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Learn about the best practices for using Connector Builder.

## Best Practices

- Keep conversations concise and use `@Conversation`. After about 10 interactions, most models begin
  to lose context and might start hallucinating.

- Make use of `@Docs`.

- Use `·@` to reference files in the codebase whenever possible.

- Commit frequently and don’t hesitate to discard changes: If Cursor (especially in Agent mode)
  introduces an error, avoid asking it to roll back. Instead, use the **Restore Checkpoint** feature
  or revert the changes yourself using git.

- Enable and configure Auto-run mode. When enabled, the Cursor agent can execute tools (such as
  running `mvn compile`) without asking for confirmation, and use the output to fix errors or
  address warnings. You can also define prompts to control the actions the Cursor agent is permitted
  to take.

- Plan before you implement. Use `.markdown` files to track progress and break work into small,
  manageable tasks.

<!-- document id=7f32855da32e6879a5a9d8aaf635f1799a5c0ee51df5a44a9b25106e4babf16e url=/mulesoft/current/en-us/connector-builder/connections.md -->

---
product: Connector Builder
version: master
---

# Connections

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Learn how to define connections for your connector. Connections enable your connector to communicate
with external systems. Without a connection, your connector can’t perform operations, triggers, or
other components. Connector Builder supports creating connectors that integrate with SaaS
applications that use HTTP-based connectivity.

Each connection uses an authentication type. An authentication type is a specific method or protocol
used to verify and authorize access to the external system. Connector Builder supports these
authentication types for connections.

- **ApiKey**

  ApiKey authentication connects to applications without explicitly defining a user. You must add
  this key to all requests, and the cloud application identifies the origin of the request and
  completes the authorization.

- **Basic**

  Basic authentication enables the user to provide a username and password when logging in to an
  external system.

- **Bearer**

  Bearer authentication sends a header named Authorization with a value of Bearer and a token with
  every request.

- **OAuth2BrowserFlow**

  OAuth2BrowserFlow authentication is the authorization code grant type, which is used to obtain
  both access tokens and refresh tokens and is optimized for confidential clients. Since this is a
  redirection-based flow, the client must be capable of interacting with the resource owner’s
  user-agent (typically a web browser) and capable of receiving incoming requests (via redirection)
  from the authorization server.

- **OAuth2ClientCredentials**

  OAuth2ClientCredentials authentication obtains an access token from a user-defined path.

> [!NOTE] Custom Flow connectors support only the **ApiKey**, **Basic**, and **Bearer**
> authentication types.

You can define connections using either the UI or LinkWeave. Use the UI as your primary approach, as
it significantly reduces manual development effort. Reserve LinkWeave for advanced scenarios that
require custom logic. With Connector Builder, the goal is to focus on reviewing and validating the
generated process, rather than writing custom code.

## Define Connections Using the UI

When you [generate base connectivity](https://docs.mulesoft.com/connector-builder/base-connectivity), if the authentication type specified in
the API specification or by AI assistance is supported by Connector Builder, the authentication type
and a connection for each endpoint are automatically defined for you.

### Use Connection Profiles

Create, edit, and manage reusable connection profiles with secure credential storage.

1.  Open the Connector Builder extension in VS Code or Cursor.

2.  Select **Connection Profiles**.

3.  Click **New Profile**.

4.  Enter the required information.

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Description</th></tr></thead><tbody><tr><td><p><strong>Profile Name</strong></p></td><td><p>Enter the name of the connection profile. For example, <code>Salesforce Developer</code>.</p></td></tr><tr><td><p><strong>Description</strong></p></td><td><p>Enter the optional description of the connection profile.</p></td></tr><tr><td><p><strong>Authentication Type</strong></p></td><td><div><div><p>Select the authentication type for the connection profile. Values are:</p></div><div><ul><li><p><code>BEARER</code></p></li><li><p><code>BASIC</code></p></li><li><p><code>OAUTH</code></p></li><li><p><code>APIKEY</code></p></li></ul></div></div></td></tr></tbody></table>

5.  Click **Save**.

There’s also a **Try It** panel that allows you to create or test the connection profile. You can
select the connection profile or add inline credentials to test your connection.

#### List Connection Profiles with MCP Tools

In some cases, you might need a list of your connection profiles. For example, to use the
`uc_manage_operations` MCP tool to
[execute operations](https://docs.mulesoft.com/connector-builder/operations#manage-operations-with-mcp-tools), you need the connection profile
ID, which can be obtained by listing your connection profiles.

1.  Open the Connector Builder extension in Cursor.

2.  Select **Settings** and ensure **Enable Mcp Tools** is enabled.

3.  Open the Cursor chat window (if not already open).

4.  Ask the agent to list connection profiles. For example, enter `List connection profiles`. This
    calls the `uc_list_connection_profiles` MCP tool, which lists the connection profiles.

5.  Enter the required inputs when prompted.

6.  Confirm your inputs. Connector Builder lists the connection profiles.

For more information, see
[MuleSoft DX MCP Server Tool Reference](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools).

## Define Connections Using LinkWeave

You can define connections using LinkWeave.

- [Connection Structure](#connection-structure)

- [Authentication Types](#authentication-types)

### Connection Structure

In LinkWeave, connections are functions that transform requests into responses:

```none
(ConnectionRequest) -> ConnectionResponse
```

For HTTP-based connections, this becomes:

```none
(HttpRequester) -> HttpResponse
```

These types form the structure of connections.

- [Connection](#connection): Connection function

- [ConnectionProvider](#connection-provider): Connection creation and configuration

- [HTTPConnection](#http-connection): Specialized connection for HTTP requests

- [HTTPConnectionProvider](#http-connection-provider): HTTP-specific connection provider

#### Connection

```none
Connection<ConnectionRequest <: Object, ConnectionResponse <: Object> =
  (ConnectionRequest) -> ConnectionResponse
```

Parameters:

- `ConnectionRequest`: Object sent to the target system

- `ConnectionResponse`: Object returned from the target system

#### ConnectionProvider

```none
ConnectionProvider<ConnectionType <: Connection, InputType <: Object, AuthenticationType <: Object>
```

Parameters:

- `ConnectionType`: Connection function itself

- `InputType`: Input parameters required to create the connection

- `AuthenticationType`: Authentication schema

`ConnectionProvider` returns an object with these properties:

```none
{
  connect: (InputType) -> ConnectionType,
  authenticationType: AuthenticationType,
  validate?: (ConnectionType) -> ConnectionValidationResult
}
```

Properties:

- `connect`: Creates a connection from input parameters

- `authenticationType`: Defines the authentication schema

- `validate`: (Optional) Tests the connection and returns validation results

#### HTTPConnection

```none
HttpConnection = Connection<HttpRequester, HttpResponse>
```

#### HTTPConnectionProvider

```none
HttpConnectionProvider<InputType <: Object, HttpAuthenticationType> =
  ConnectionProvider<HttpConnection, InputType, HttpAuthenticationType>
```

`HTTPConnectionProvider` also supports an optional `extensions` attribute for customizing connection
behavior. Use extensions to add custom headers, query parameters, or other modifications to
requests.

```none
extensions?: (InputType) -> Array<ConnectionProviderExtensions | ConnectionProviderOAuthExtensions>
```

The definitions for these types are:

```none
type ConnectionProviderExtensions = {
  in: "query" | "header" | "body" | "path",
  name: String,
  value: String
}

type ConnectionProviderOAuthExtensions = {
  inDance: true | false,
} & ConnectionProviderExtensions
```

You can also enhance any authentication type with extensions. This example adds a static header to a
Basic authentication type.

```none
@ConnectionElement()
  var basicAuth = defineBasicHttpConnectionProvider<BasicAuthSchema & { baseUri: String }>((schema) -> {
    username: schema.username,
    password: schema.password
  }, (schema) -> {
    baseUri: schema.baseUri
  }),
  (schema) -> [
                  {in: "header", name:"customHeaderStatic", value: "myValue"}
                ] //This extensions attribute is optional
```

### Authentication Types

You can define the connections for authentication types.

- [ApiKey](#apikey)

- [Basic](#basic)

- [Bearer](#bearer)

- [OAuth2](#oauth2)

#### ApiKey

```none
@ConnectionElement()
  var apiKeyAuth = defineApiKeyHttpConnectionProvider<ApiKeyAuthSchema & { baseUri: String }>((schema) -> {
    apiKey: schema.apiKey
  }, (schema) -> {
    baseUri: schema.baseUri
  }, {
    in: "header",
    name: "X-ApiKey"
  })
```

The APIKey connection is defined and created using `ApiKeyAuthSchema`, which is the input connection
type definition and the connection parameters.

The `defineApiKeyHttpConnectionProvider` function requires these parameters.

- `schemaMapper`

  From an input, `schemaMapper` returns `ApiKeyAuthSchema`.

  ```none
  type ApiKeyAuthSchema = {|
        apiKey: @SemanticTerms(value = ["apiKey"]) String
    |}
  ```

- `connectionProviderSchemaMapper`

  From an input, `connectionProviderSchemaMapper` returns `HttpConnectionProviderSchema`.

  ```none
  type HttpConnectionProviderSchema = {
    baseUri?: String
  }
  ```

- `attributes`

  `attributes` returns `ApiKeyAuthAttributesSchema`.

  ```none
  type ApiKeyAuthAttributesSchema = {
    in: 'header' | 'cookie' | 'query',
    name: String
  }
  ```

> [!NOTE] LinkWeave supports a schema based on a single API key.

#### Basic

```none
@ConnectionElement()
  var basicAuth = defineBasicHttpConnectionProvider<BasicAuthSchema & { baseUri: String }>((schema) -> {
    username: schema.username,
    password: schema.password
  }, (schema) -> {
    baseUri: schema.baseUri
  })
```

The Basic connection is defined and created using `BasicAuthDefinition`, which is the input
connection type definition and the connection parameters.

The `defineBasicHttpConnectionProvider` function requires these parameters.

- `schemaMapper`

  From an input, `schemaMapper` returns `BasicAuthSchema`.

  ```none
  type BasicAuthSchema = {
    username: @SemanticTerms(value = ["username"]) String,
    password: @SemanticTerms(value = ["password"]) String
  }
  ```

- `connectionProviderSchemaMapper`

  From an input, `connectionProviderSchemaMapper` returns `HttpConnectionProviderSchema`.

  ```none
  type HttpConnectionProviderSchema = {
    baseUri?: String
  }
  ```

#### Bearer

```none
@ConnectionElement()
  var bearerAuth = defineBearerHttpConnectionProvider<BearerAuthSchema & { baseUri: String }>((schema) -> {
    token: schema.token
  }, (schema) -> {
    baseUri: schema.baseUri
  })
```

The Bearer connection is defined and created using `BearerAuthSchema`, which is the input connection
type definition and the connection parameters.

The `defineBearerHttpConnectionProvider` function requires these parameters.

- `schemaMapper`

  From an input, `schemaMapper` returns `BearerAuthSchema`.

  ```none
  type BearerAuthSchema = {
    token: @SemanticTerms(value = ["secretToken"]) String
  }
  ```

- `connectionProviderSchemaMapper`

  From an input, `connectionProviderSchemaMapper` returns `HttpConnectionProviderSchema`.

  ```none
  type HttpConnectionProviderSchema = {
    baseUri?: String
  }
  ```

#### OAuth2

```none
@ConnectionElement()
type OAuthAuthDefinition = {
       baseUri: String,
       accessToken: @SemanticTerms(value = ["password"]) String
}

var oAuth: defineOAuth2Connection<OAuthAuthDefinition>(
       (parameter) -> {accessToken: parameter.accessToken},
       (parameter) -> {baseUri: parameter.baseUri},
       {
           grantType: 'authorizationCode',
           authorizationUrl: "http://localhost/authorize",
           tokenUrl: "http://localhost/token",
           scopes: ["test"]
       }
     )
```

The OAuth2 connection is defined and created using `OAuthAuthDefinition`, which is the input
connection type definition and the connection parameters.

The `defineOAuth2Connection` function requires these parameters.

- `schemaMapper`

  From an input, `schemaMapper` returns `OAuth2AuthSchema`.

  ```none
  type OAuth2AuthSchema = {|
    accessToken: @SemanticTerms(value = ["password"]) String
  |}
  ```

- `connectionSchemaMapper`

  From an input, `connectionSchemaMapper` returns `HttpConnectionProviderSchema`.

  ```none
  type HttpConnectionProviderSchema = {|
    baseUri?: String
  |}
  ```

- `attributes`

  `attributes` returns `OAuth2Schema`.

  ```none
  type OAuth2Schema<OAuthGrantType <: AuthorizationCodeGrantType | ClientCredentialsGrantType | PasswordGrantType | ImplicitGrantType> = OAuthGrantType
  ```

OAuth2 supports these grant types.

- `authorizationCode`

- `clientCredentials`

Each grant type has specific configuration requirements. For example, for `authorizationCode`:

```none
type GrantType = 'authorizationCode' | 'clientCredentials' | 'password' | 'implicit'

type CommonOAuth2GrantTypeSchema<GrantType> = {|
  "grantType": GrantType,
  refreshUrl?: String,
  scopes: Array<String>
|}

type AuthorizationCodeGrantType = CommonOAuth2GrantTypeSchema<'authorizationCode'> & {|
  authorizationUrl: String,
  tokenUrl: String
|}
```

<!-- document id=1dea1a56f9a3f47d57c00fdcda5c69293816cbefc909492e730c1e3404a6cc07 url=/mulesoft/current/en-us/connector-builder/index.md -->

---
product: Connector Builder
version: master
---

# Connector Builder Overview

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Use Connector Builder to create your own connectors easily. Connector Builder is an extension that
streamlines and accelerates connector development by creating connectors either from an API
specification (OAS 3.0), AI assistance (available when using Cursor), or MCP tools (available when
using Cursor). These connectors integrate with SaaS applications that use HTTP-based connectivity.

Connector Builder supports these connectivity platforms:

- Anypoint Platform

  Anypoint Connectors that run in Mule applications

- Salesforce Flow

  Flow connectors that run in Salesforce Flow

The same connector project can target either platform. All Connector Builder features are available
for both Anypoint and Flow connectors.

Connector Builder creates connectors by using LinkWeave, which is a connectivity language built on
top of DataWeave. Connector Builder is UI-first, so you don’t need LinkWeave knowledge to create
connectors. However, for advanced use cases, you can use LinkWeave to extend and enhance
functionality by adding custom capabilities.

## Key Advantages

Some key advantages of using Connector Builder are:

- **Speed**

  Reduce development time from months to days or even minutes.

- **Simplicity**

  Eliminate system-specific code, static assets, and scripting.

- **Scalability**

  Build scalable connectivity that handles thousands of APIs with unique implementations.

- **Quality**

  Maximize consistency and reliability by reducing manual input and enforcing reusable design
  patterns.

- **Usability**

  Get a unified, intuitive design experience for both developers and non-developers.

- **Customization**

  Create your own connectors if they don’t already exist, and tailor them to your requirements.

## Supported Features

Connectors built with Connector Builder can support:

- [Base Connectivity](https://docs.mulesoft.com/connector-builder/base-connectivity)

- [Connections](https://docs.mulesoft.com/connector-builder/connections)

- [Operations](https://docs.mulesoft.com/connector-builder/operations)

- [Pagination](https://docs.mulesoft.com/connector-builder/pagination)

- [Triggers](https://docs.mulesoft.com/connector-builder/triggers)

- [Value Providers](https://docs.mulesoft.com/connector-builder/value-providers)

After you create your connector, you can [test](https://docs.mulesoft.com/connector-builder/testing-connectors),
[package](https://docs.mulesoft.com/connector-builder/packaging-connectors), [release](https://docs.mulesoft.com/connector-builder/releasing-connectors), and [run](https://docs.mulesoft.com/connector-builder/running-connectors) your
connector.

## Use Cases

Use Connector Builder to create a wide range of connectors. Some use cases include:

- **CRM**

  Sync customer data, manage leads, and automate sales processes.

- **ERP**

  Integrate financials, manage inventory, and streamline supply chain operations.

- **Marketing**

  Plan campaigns, track customer interactions, and automate outreach workflows.

- **E-commerce**

  Manage product catalogs, process orders, and handle customer data.

- **HR Management**

  Handle employee data, run payroll, and administer benefits.

- **Collaboration**

  Automate notifications, manage tasks, and streamline project workflows.

- **Social Media**

  Publish content, track analytics, and enable social engagement.

- **Payment Gateways**

  Process payments, manage transactions, and handle financial data.

## Next Steps

For information about prerequisites, installations, and upgrades, refer to
[Getting Started](https://docs.mulesoft.com/connector-builder/getting-started).

<!-- document id=ee91624f3f22ebadafc1f07d40fff18e9bc03d980db4d3f092c6b7f6ca07bd69 url=/mulesoft/current/en-us/connector-builder/connector-builder-release-notes.md -->

---
product: Connector Builder
version: master
---

# Connector Builder Release Notes

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Use Connector Builder to create your own connectors easily. Connector Builder is an extension that
streamlines and accelerates connector development by creating connectors either from an API
specification (OAS 3.0), AI assistance (available when using Cursor), or MCP tools (available when
using Cursor). These connectors integrate with SaaS applications that use HTTP-based connectivity.

For more information, see [Connector Builder Overview](https://docs.mulesoft.com/connector-builder/).

## 1.5.2

**September 21, 2026**

### What’s New

This release includes only non-user-impacting changes.

### Compatibility

<table><colgroup><col> <col></colgroup><thead><tr><th>Software</th><th>Version</th></tr></thead><tbody><tr><td><p>Mule runtime engine</p></td><td><p>4.10 and later</p></td></tr></tbody></table>

## 1.5.0

**July 22, 2026**

### What’s New

- Connector Builder now includes usage telemetry to help improve the product. For more information,
  see [Telemetry in Connector Builder](https://docs.mulesoft.com/connector-builder/telemetry).

- After the latest pre-release (Connector Builder 1.4.0), Connector Builder again supports
  generating Anypoint connectors alongside Flow connectors.

### Compatibility

<table><colgroup><col> <col></colgroup><thead><tr><th>Software</th><th>Version</th></tr></thead><tbody><tr><td><p>Mule runtime engine</p></td><td><p>4.10 and later</p></td></tr></tbody></table>

## 1.4.0

**June 2, 2026**

> [!IMPORTANT] Connector Builder 1.4 is a pre-release that supports creating Flow connectors only.
> To create Anypoint connectors, use any other version of Connector Builder.

### What’s New

- You can now use Connector Builder to create Flow connectors that run in Salesforce Flow. All
  Connector Builder features are available for both Anypoint and Flow connectors.

- These new MCP tools are available for use in Connector Builder. See
  [MuleSoft DX MCP Server Tool Reference](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools).

  - `uc_get_test_generation_info`

    See [Generate Tests With MCP Tools](https://docs.mulesoft.com/connector-builder/testing-connectors#generate-tests-with-mcp-tools).

  - `uc_generate_tests`

    See [Generate Tests With MCP Tools](https://docs.mulesoft.com/connector-builder/testing-connectors#generate-tests-with-mcp-tools).

- These MCP tools are renamed in this version.

  - `uc_generate_api_spec` is renamed to `uc_manage_api_spec`. The renamed tool also supports
    research-only and validation modes. See
    [Generate Base Connectivity with MCP Tools](https://docs.mulesoft.com/connector-builder/base-connectivity#generate-base-connectivity-with-mcp-tools).

  - `uc_publish_connector` is renamed to `uc_connector_lifecycle`. The renamed tool supports both
    `build` and `publish` actions. See
    [Package Connectors with MCP Tools](https://docs.mulesoft.com/connector-builder/packaging-connectors#package-connectors-with-mcp-tools) and
    [Release Connectors to Anypoint Platform with MCP Tools](https://docs.mulesoft.com/connector-builder/releasing-connectors#release-connectors-to-anypoint-platform-with-mcp-tools).

- You can now execute operations directly from the editor at design time using the Try It panel,
  without packaging or deploying the connector. The Try It panel is available for all operations,
  regardless of platform. See
  [Execute Operations Using the Try It Panel](https://docs.mulesoft.com/connector-builder/operations#execute-operations-try-it).

### Compatibility

<table><colgroup><col> <col></colgroup><thead><tr><th>Software</th><th>Version</th></tr></thead><tbody><tr><td><p>Mule runtime engine</p></td><td><p>4.10 and later</p></td></tr></tbody></table>

## 1.3.0

**March 6, 2026**

### What’s New

- These new MCP tools are available for use in Connector Builder. See
  [MuleSoft DX MCP Server Tool Reference](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools).

  - `uc_add_pagination`

    See [Define Pagination with MCP Tools](https://docs.mulesoft.com/connector-builder/pagination#define-pagination-with-mcp-tools).

  - `uc_list_connection_profiles`

    See
    [List Connection Profiles with MCP Tools](https://docs.mulesoft.com/connector-builder/connections#list-connection-profiles-with-mcp-tools).

  - `uc_manage_operations`

    See [Manage Operations with MCP Tools](https://docs.mulesoft.com/connector-builder/operations#manage-operations-with-mcp-tools).

  - `uc_publish_connector`

    See
    [Release Connectors to Anypoint Platform with MCP Tools](https://docs.mulesoft.com/connector-builder/releasing-connectors#release-connectors-to-anypoint-platform-with-mcp-tools).

- You can now create connection profiles in Connector Builder. See
  [Use Connection Profiles](https://docs.mulesoft.com/connector-builder/connections#use-connection-profiles).

- You can now generate tests for your Anypoint Connectors. See
  [Testing Connectors](https://docs.mulesoft.com/connector-builder/testing-connectors).

- You can now specify your own base package and Maven group ID for connectors, rather than using the
  default values (`com::mulesoft::connectivity` for the base package and `com.mulesoft.connectivity`
  for the Maven group ID).

- The UI for creating a new project is improved. See [Base Connectivity](https://docs.mulesoft.com/connector-builder/base-connectivity).

### Compatibility

<table><colgroup><col> <col></colgroup><thead><tr><th>Software</th><th>Version</th></tr></thead><tbody><tr><td><p>Mule runtime engine</p></td><td><p>4.10 and later</p></td></tr></tbody></table>

## 1.2.0

**December 18, 2025**

### What’s New

- Connector Builder now automatically performs pre-publish validation tasks before publishing
  connectors to Anypoint Exchange. The improved publishing workflow checks and updates `pom.xml`
  files to validate group IDs and distribution management settings. It also checks `settings.xml`
  for Anypoint credentials configuration and provides code snippets to help you configure
  authentication. Any formatting errors in these files are now displayed directly in the UI for
  quick resolution.

- Version information is now retrieved from the Language Server instead of the CLI, improving
  accuracy and reliability of dependency version management in project metadata.

- Connector name validation now enforces a 20-character limit to prevent malfunction during
  connector operations.

- The default Maven repository ID in the Anypoint `pom.xml` file is now set to `Repository`.

- Maven profiles are added to configure private Exchange deployment and remove unnecessary artifacts
  during publishing.

### Compatibility

<table><colgroup><col> <col></colgroup><thead><tr><th>Software</th><th>Version</th></tr></thead><tbody><tr><td><p>Mule runtime engine</p></td><td><p>4.10 and later</p></td></tr></tbody></table>

### Fixed Issues

<table><colgroup><col> <col></colgroup><thead><tr><th>Issue Resolution</th><th>ID</th></tr></thead><tbody><tr><td><div><div><p>Text in operation types no longer overflows and is readable for all transformed operations, including paginated CCM operations.</p></div></div></td><td><div><div><p>W-20295471</p></div></div></td></tr><tr><td><div><div><p>Version comparison logic during project regeneration now properly detects version mismatches and displays correct values in comparison pop-ups.</p></div></div></td><td><div><div><p>W-20406985</p></div></div></td></tr></tbody></table>

## 1.1.1

**December 18, 2025**

The features and fixed issues for this version are in version 1.2.0.

## 1.1.0

**November 20, 2025**

### What’s New

- You can now use the MuleSoft MCP Server to build connectors with Connector Builder. For more
  information, see
  [MuleSoft DX MCP Server Tool Reference](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools) and
  [Generate Base Connectivity with MCP Tools](https://docs.mulesoft.com/connector-builder/base-connectivity#generate-base-connectivity-with-mcp-tools).
  These new MCP tools are available for use in Connector Builder.

  - `uc_create_connector_workflow`

  - `uc_generate_api_spec`

  - `uc_generate_connector`

- You can now easily publish connectors to Anypoint Exchange with the improved UI, which clearly
  guides you through each step of the publishing process. For more information, see
  [Release Connectors to Anypoint Platform](https://docs.mulesoft.com/connector-builder/releasing-connectors#release-connectors-to-anypoint-platform).

### Compatibility

<table><colgroup><col> <col></colgroup><thead><tr><th>Software</th><th>Version</th></tr></thead><tbody><tr><td><p>Mule runtime engine</p></td><td><p>4.10 and later</p></td></tr></tbody></table>

## 1.0.0

**October 22, 2025**

### What’s New

- Connector Builder is now generally available.

### Compatibility

<table><colgroup><col> <col></colgroup><thead><tr><th>Software</th><th>Version</th></tr></thead><tbody><tr><td><p>Mule runtime engine</p></td><td><p>4.10 and later</p></td></tr></tbody></table>

## See Also

- [Salesforce Help](https://help.salesforce.com)

- [MuleSoft Services](https://www.mulesoft.com/support-and-services)

- [Troubleshooting Connector Builder](https://docs.mulesoft.com/connector-builder/troubleshooting)

- [Known Issues](https://help.salesforce.com/s/issues)

<!-- document id=f0c25209dc0bba99679ba0a1b917c3415b68b669b930ac4ed76f40297c794b11 url=/mulesoft/current/en-us/connector-builder/creating-connectors.md -->

---
product: Connector Builder
version: master
---

# Creating Connectors

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Learn how to create connectors with Connector Builder. Connector Builder supports these components
for your connectors.

- [Base Connectivity](https://docs.mulesoft.com/connector-builder/base-connectivity)

- [Connections](https://docs.mulesoft.com/connector-builder/connections)

- [Operations](https://docs.mulesoft.com/connector-builder/operations)

- [Pagination](https://docs.mulesoft.com/connector-builder/pagination)

- [Triggers](https://docs.mulesoft.com/connector-builder/triggers)

- [Value Providers](https://docs.mulesoft.com/connector-builder/value-providers)

<!-- document id=aa228d6323c718080a9ba5c138f7290e38c53e69c72fecfb529998f3e983e356 url=/mulesoft/current/en-us/connector-builder/getting-started.md -->

---
product: Connector Builder
version: master
---

# Getting Started

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Learn about Connector Builder prerequisites, installations, and upgrades.

## Prerequisites

To create connectors with Connector Builder, your system must meet these prerequisites.

### OS Platforms

Your OS must be one of these:

- macOS (Intel or Apple Silicon) versions with Apple security update support. This is typically the
  latest release and the two previous versions.

- Windows 10 or 11 (64-bit)

  > [!NOTE] Windows 10 is deprecated on
  > [October 14, 2025](https://support.microsoft.com/en-us/windows/windows-10-support-has-ended-on-october-14-2025-2ca8b313-1946-43d3-b55c-2b95b107f281).

### Hardware

- Minimum system requirements:

  - 10 GB of free storage space

  - 8 GB of RAM

- Recommended system requirements:

  - 20 GB of free storage space

  - 16 GB of RAM

### Software

#### Anypoint Connectors

- Required software:

  - [VS Code](https://code.visualstudio.com/download) 1.99.3 and later, or
    [Cursor](https://cursor.com/docs) 1.5.9 and later

    Cursor offers several advantages:

    - AI assistance for
      [base connectivity](https://docs.mulesoft.com/connector-builder/base-connectivity#generate-base-connectivity-with-ai-assistance),
      [pagination](https://docs.mulesoft.com/connector-builder/pagination#define-pagination-with-ai-assistance),
      [generating tests](https://docs.mulesoft.com/connector-builder/testing-connectors#generate-tests-with-ai-assistance), and
      [running tests](https://docs.mulesoft.com/connector-builder/testing-connectors#run-tests-with-ai-assistance)

    - MCP tools for
      [base connectivity](https://docs.mulesoft.com/connector-builder/base-connectivity#generate-base-connectivity-with-mcp-tools),
      [connection profiles](https://docs.mulesoft.com/connector-builder/connections#list-connection-profiles-with-mcp-tools),
      [operations](https://docs.mulesoft.com/connector-builder/operations#manage-operations-with-mcp-tools),
      [pagination](https://docs.mulesoft.com/connector-builder/pagination#define-pagination-with-mcp-tools),
      [generating tests](https://docs.mulesoft.com/connector-builder/testing-connectors#generate-tests-with-mcp-tools),
      [packaging connectors](https://docs.mulesoft.com/connector-builder/packaging-connectors#package-connectors-with-mcp-tools), and
      [releasing connectors](https://docs.mulesoft.com/connector-builder/releasing-connectors#release-connectors-to-anypoint-platform-with-mcp-tools)

  - [Connector Builder VS Code extension](https://marketplace.visualstudio.com/items?itemName=salesforce.connectivity-tooling-ic-vscode-extension&ssr=false#version-history),
    any version except 1.4.0. Connector Builder 1.4.0 was a pre-release for Flow connectors only.

  - Dependent VS Code extensions

    You must have these dependent extensions if you use your connector in Anypoint Code Builder or
    Anypoint Studio. If you use VS Code, the latest versions of these extensions are automatically
    installed when you install the Connector Builder extension. If you use Cursor, you must update
    your user settings, and then install the Connector Builder extension to have the latest versions
    of these extensions automatically installed. For more information, see
    [Install Connector Builder](#install-uc-builder).

    - [Anypoint Code Builder - Platform Extension](https://marketplace.visualstudio.com/items?itemName=salesforce.mule-dx-vscode)
      version 5.7.2 and later

    - [Anypoint Code Builder - DataWeave Extension](https://marketplace.visualstudio.com/items?itemName=salesforce.mule-dx-data-weave-client)
      version 2.10.6 and later

    - [Anypoint Code Builder - Dependencies Extension](https://marketplace.visualstudio.com/items?itemName=salesforce.mule-dx-dependencies)
      version 1.6.0 and later

- Recommended software:

  - [Anypoint Extension Pack](https://marketplace.visualstudio.com/items?itemName=salesforce.mule-dx-extension-pack)

  - [Anypoint Code Builder - API Extension](https://marketplace.visualstudio.com/items?itemName=salesforce.mule-dx-api-component)

  - Anypoint Studio or Anypoint Code Builder

#### Flow Connectors

##### Customer Requirements

To install and use a custom Flow connector, a customer org needs:

- Edition: Enterprise, Unlimited, or Developer.

- MuleSoft for Flow add-on, which provides the runtime that executes connector operations. Each
  operation consumes Automation Credits.

- User permissions required to configure a connection and use connectors in Flow:

  - To create, view, edit, and delete MuleSoft for Flow: Integration connections: **Manage
    Integration Connections**

  - To open, edit, create, activate or deactivate a flow using all flow types, elements, and
    features available in Flow Builder, including Einstein and Agentforce for Flow: **Manage Flow**

  - To create and edit External System Change-Triggered flows in the Automation app, regardless of
    sharing settings: **Manage Flow** OR **Create or Edit Flows** AND **View Flows**, **View All
    Non-Admin Flows**

  - To create and edit External System Change-Triggered flows owned by or shared with you with
    Read/Write access in the Automation app: **Create or Edit Flows** AND **View Flows**

  - To use MuleSoft for Flow: Integration templates: **Create or Edit Flows** OR **View Flows**

##### Partner Requirements (For ISVs Publishing to AgentExchange)

> [!NOTE] When you author DataWeave transformations in Connector Builder, follow the guidelines in
> [Secure Your Flow Connectors](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/secure_code_secure_your_flow_connectors.htm?_gl=1*1uebz97*_gcl_au*MTM3MjI0OTYwMi4xNzgyNzQ1NDg1&_ga=2.125517833.262923442.1782745486-378704745.1773886412).
> The AgentExchange Security Review checks for the issues described there, so addressing them during
> authoring avoids submission rejection later.

To build and deploy a custom Flow connector for AgentExchange, you need:

- [VS Code](https://code.visualstudio.com/download) 1.99.3 and later, or
  [Cursor](https://cursor.com/docs) 1.5.9 and later

  Cursor offers several advantages:

  - AI assistance for
    [base connectivity](https://docs.mulesoft.com/connector-builder/base-connectivity#generate-base-connectivity-with-ai-assistance),
    [pagination](https://docs.mulesoft.com/connector-builder/pagination#define-pagination-with-ai-assistance),
    [generating tests](https://docs.mulesoft.com/connector-builder/testing-connectors#generate-tests-with-ai-assistance), and
    [running tests](https://docs.mulesoft.com/connector-builder/testing-connectors#run-tests-with-ai-assistance)

  - MCP tools for [base connectivity](https://docs.mulesoft.com/connector-builder/base-connectivity#generate-base-connectivity-with-mcp-tools),
    [connection profiles](https://docs.mulesoft.com/connector-builder/connections#list-connection-profiles-with-mcp-tools),
    [operations](https://docs.mulesoft.com/connector-builder/operations#manage-operations-with-mcp-tools),
    [pagination](https://docs.mulesoft.com/connector-builder/pagination#define-pagination-with-mcp-tools),
    [generating tests](https://docs.mulesoft.com/connector-builder/testing-connectors#generate-tests-with-mcp-tools), and
    [packaging connectors](https://docs.mulesoft.com/connector-builder/packaging-connectors#package-connectors-with-mcp-tools)

- [Connector Builder VS Code extension](https://marketplace.visualstudio.com/items?itemName=salesforce.connectivity-tooling-ic-vscode-extension&ssr=false#version-history),
  version 1.4.0 and later.

- A Dev Hub-enabled org for development and packaging.

- Salesforce CLI (sf) installed locally.

- The **ExternalConnectivity** org permission on your scratch org. This permission lets you build,
  deploy, and test custom Flow connectors in that org.

- The MuleSoft for Flow add-on enabled on your dev hub org. The add-on provides the runtime that
  executes connector operations. Without it, you can deploy the connector metadata but you can’t
  exercise the connector end-to-end against the external system.

- Registration as a partner under the AgentExchange Partner Program and access to Partner Console.

## Install Connector Builder

Install Connector Builder in VS Code or Cursor.

### Install Connector Builder in VS Code

1.  In VS Code, select the Extensions icon in the Activity Bar.

2.  Search for `Connector Builder` in the marketplace.

3.  Click **Install** on the extension.

### Install Connector Builder in Cursor

1.  Go to **View** > **Command Palette**.

2.  Enter `Preferences: Open User Settings`.

3.  Go to **Features** > **Extensions** > **Gallery: Service Url**.

4.  Enter `https://marketplace.visualstudio.com/_apis/public/gallery`.

    > [!NOTE] If you skip this step, you must install the dependent extensions manually.

5.  Restart Cursor.

6.  Go to **View** > **Extensions**.

7.  Search for `Connector Builder` in the marketplace.

8.  Click **Install** on the extension.

## Upgrade Connector Builder

To ensure you’re using the latest version of Connector Builder, select the Connector Builder
extension in VS Code or Cursor and then select the **Auto Update** checkbox.

<!-- document id=e5020bfa0bd00585daea4116cbe973c7f2b321c798e3bb78e2edb8abdfdf2988 url=/mulesoft/current/en-us/connector-builder/limitations.md -->

---
product: Connector Builder
version: master
---

# Limitations of Connector Builder

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Learn about the limitations of using Connector Builder.

## Limitations

- Requesting more than six use cases might cause hallucinations.

- Large API specifications might cause scope dilution.

<!-- document id=a5adebf24e00aa8a0dea3b855b8ba561b1db985150b1da4f1829c013917f4403 url=/mulesoft/current/en-us/connector-builder/operations.md -->

---
product: Connector Builder
version: master
---

# Operations

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Learn how to define operations for your connector. Operations are the actions that your connector
can perform, for example, CRUD (Create, Read, Update, Delete) operations. Platform-specific
operations are defined as transformations of the canonical connectivity model (CCM) operations.

You can define operations using either the UI or LinkWeave. Use the UI as your primary approach, as
it significantly reduces manual development effort. Reserve LinkWeave for advanced scenarios that
require custom logic. With Connector Builder, the goal is to focus on reviewing and validating the
generated process, rather than writing custom code.

## Define Operations Using the UI

When you [generate base connectivity](https://docs.mulesoft.com/connector-builder/base-connectivity), the operations defined in your API
specification or AI assistance are automatically displayed as API endpoints. You can choose which
operations to include in your connector by selecting or deselecting them.

If you have already generated base connectivity and want to modify the set of operations included
from your API specification or AI assistance, select **Generate** > **Regenerate Project** and
choose which operations to add or remove.

If you have already generated base connectivity and want to add operations that aren’t present in
the API specification or AI assistance, update the API specification or AI input with the new
operations, and then regenerate base connectivity.

### Execute Operations Using the Try It Panel

The Try It panel lets you execute any operation directly from the editor at design time, without
packaging or deploying the connector. The Try It panel is available for all operations, regardless
of platform and regardless of whether they’re associated with a generated connector.

1.  In the **Operations Explorer**, select an operation. The **Try It** panel appears on the right.

2.  Select the authentication to use. You can either:

    - Use a **connection profile** (reusable credentials). Select an existing profile, or create a
      new one. See [Use Connection Profiles](https://docs.mulesoft.com/connector-builder/connections#use-connection-profiles).

    - Use **inline credentials** (fire-and-forget). The Credentials Editor appears, pre-populated
      with the expected JSON schema for the selected authentication scheme. Fill in the values.
      Inline credentials are discarded when you select a different operation.

3.  In the **Input** editor, provide input for the operation. The Input editor is pre-populated with
    the expected JSON schema, including all fields. Required and optional fields are both shown.
    Modify the values you need and remove any optional fields you don’t want to send.

4.  Click **Run**.

5.  After the operation completes, the panel displays the result status and the response body.

6.  If the operation supports pagination and additional pages are available, **Previous** and
    **Next** buttons appear. Click them to re-execute the operation against the corresponding page.

### Manage Operations with MCP Tools (Cursor)

1.  Open the Connector Builder extension in Cursor.

2.  Select **Settings** and ensure **Enable Mcp Tools** is enabled.

3.  Open the Cursor chat window (if not already open).

4.  Ask the agent to manage operations. For example, enter `List operations`,
    `Get operation details`, or `Execute an operation`.

    If you want to execute an operation, you need the connection profile ID. Use the
    `uc_list_connection_profiles` MCP tool first to
    [list connection profiles](https://docs.mulesoft.com/connector-builder/connections#list-connection-profiles-with-mcp-tools) to retrieve the
    ID.

5.  Enter the required inputs when prompted.

6.  Confirm your inputs. Connector Builder performs the requested action.

For more information, see
[MuleSoft DX MCP Server Tool Reference](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools).

## Define Operations Using LinkWeave

You can define operations using LinkWeave.

- [Operation Structure](#operation-structure)

- [Operation Decorators](#operation-decorators)

- [HTTP Operations](#http-operations)

- [Operation Errors](#operation-errors)

### Operation Structure

Each operation consists of:

- `name`: An internal identifier for the operation.

- `displayName`: The user-facing name shown in the UI.

- `executor`: The function that implements the operation logic.

Operation invocations can either succeed or fail. A successful invocation returns `ResultSuccess`,
while a failure returns `ResultFailure`. The meaning of "failure" depends on the external service
you’re integrating with.

> [!NOTE] Most HTTP services indicate errors using `4XX` or `5XX` status codes, which the HTTP
> library interprets as failures. However, some APIs always return `2XX` status codes and instead
> signal errors within the response body. For these APIs, you must inspect the response and
> explicitly signal failure in your executor.

Operations have the `Operation<ArgsT, OkT, ErrorT <: ResultFailure, ConnT>` type.

- `ArgsT`: The type of arguments required for invocation. It must be an `Object` type.

- `OkT`: The type of the successful result (`ResultSuccess<OkT>`).

- `ErrorT`: The type of the failure result (`ResultFailure<ErrorValueType, ErrorType>`), in which
  `ErrorValueType` is the error payload and `ErrorType` describes the error kind and categories.

- `ConnT`: The connection type, which is an `Object` type that describes the context required to
  invoke the operation.

Here’s an example of an operation:

```none
type DuplicateParams = {
    x: Number
}

var myOperation: Operation<DuplicateParams, Number, ResultFailure<Nothing, Error>, {}> = {
    name: "duplicate",
    displayName: "2 times X",
    executor: (args: DuplicateParams, connectionInstance) ->
      success(args.x * 2)
}
```

### Operation Decorators

The `com::mulesoft::connectivity::decorator::Operation` module provides decorators to append
additional code before or after an operation invocation. These decorators include:

- `mapInputOperation(operation, mapper)`: Transforms the input before invoking the operation,
  adapting it to the type expected by the operation.

- `mapInputPaginatedOperation(operation, mapper)`: Transforms the input before invoking a paginated
  operation, adapting it to the type expected by the operation.

- `mapOutputSuccessOperation(operation, mapper)`: Transforms the output of successful invocations
  into a more suitable shape.

- `mapOutputFailureOperation(operation, mapper)`: Transforms the output of failed invocations into a
  more suitable shape.

- `mapOutputFailurePaginatedOperation(operation, mapper)`: Transforms the output of failed
  invocations of paginated operations into a more suitable shape.

- `paginate(operation, strategy)`: Applies a pagination strategy to the output of successful
  invocations, using a function that receives both the original parameters and the successful result
  to create a `Page`.

### HTTP Operations

HTTP operations are the most common type of operation, so they have the
`com::mulesoft::connectivity::transport::Http` dedicated module. This module standardizes HTTP
operation shapes and provides utilities for parameter encoding and request execution. Here’s a
summary of the module.

- `HttpRequestBuilder`: The base type for HTTP connection instances.

- `HttpResponse<T>`: The type representing an HTTP response with a body of type `T`.

- `HttpAuthenticationType`: The type representing authentication for HTTP connections.

- `HttpConnection<ArgsT, AuthenticationType>`: The type describing an HTTP connection that requires
  parameters of type `ArgsT` and uses the specified `AuthenticationType`.

- `BasicHttpConnection<ArgsT>`: The type describing an HTTP connection using the Basic
  authentication scheme, requiring parameters of type `ArgsT`.

- `defineBasicHttpConnection(validate, mapper)`: Defines `BasicHttpConnection` by providing a
  `validate` function to check credential validity and a `mapper` function to extract the
  authentication schema from the connection parameters.

- `defineBearerHttpConnection(validate, mapper)`: Defines `BearerHttpConnection` by providing a
  `validate` function to check credential validity and a `mapper` function to extract the
  authentication schema from the connection parameters.

- `BaseAuthSchema`: The base type for all authentication schemas.

- `BasicAuthSchema`: The type describing the information required for the Basic authentication
  scheme.

- `basicAuth(schema)`: Creates an HTTP connection instance (`HttpRequestBuilder`) from
  `BasicAuthSchema`.

- `BearerAuthSchema`: The type describing the information required for the Bearer authentication
  scheme.

- `bearerAuth(schema)`: Creates an HTTP connection instance (`HttpRequestBuilder`) from
  `BearerAuthSchema`.

- `HttpOperation<ArgsT, OkT, ErrorT, ConnT>`: The type representing an HTTP operation.

- `parseQueryParameters(uri)`: Parses query parameters from the given URI.

- `addQueryParameters(resource, queryParams, config?)`: Serializes `queryParams` (using the optional
  `config`) and adds them to the specified resource.

HTTP operations have the `HttpOperation<ArgsT, OkT, ErrorT, ConnT>` type, in which:

- `ArgsT` must extend `HttpRequestType`.

- `OkT` and `ErrorT` must extend `HttpResponse`.

- `ConnT` must extend `HttpConnection`.

The `HttpRequestType` object defines these parameters for all HTTP operations.

- Query parameters (required, can be empty)

- URI/path parameters (optional)

- Header parameters (required, can be empty)

- Cookie parameters (required, can be empty)

- Body (optional)

Here’s an example of an HTTP operation with the `http://www.mulesoft.com/user/{userId}` endpoint:

```none
type GetUserByIdRequest = HttpRequestType<{|
  uri: { userId: Number },
  query: {},
  headers: {},
  cookie: {}
|}>

@OperationElement()
var GetUserByIdEndpoint: HttpOperation<GetUserByIdRequest, Any, Any, HttpConnection> = {
  name: "getUserByIdEndpoint",
  displayName: "Get user by id",
  executor: (parameter, connection) ->
    success(connection({method: "GET", path: "/user/" ++ parameter.uri.userId}) as HttpResponse<Any>)
}
```

The `parameter` variable is of type `GetUserByIdRequest`. To access individual parameter values,
reference their corresponding attributes, as shown with `parameter.uri.userId` in the example.

To perform HTTP requests, use the `request` function from `dw::io::http::Client`. To serialize
complex values for query parameters, use the `addQueryParameters` function.

#### Encoding Parameters in HTTP Operations

Before sending parameters in an HTTP request, they often need to be converted into an appropriate
string format. Specify the encoding configuration for each parameter that requires it. For example,
array query parameters must be encoded into a string when constructing the final URI, as arrays
can’t be transmitted directly. The same principle applies to URI, header, and cookie parameters,
though each type might have different encoding options. For more information about the available
encoding configurations for each parameter type, refer to
[Style Values](https://spec.openapis.org/oas/latest.html#style-values).

Here’s an example of encoding parameters in an HTTP operation:

```none
type GetUsersByCompaniesIdEndpointRequest = HttpRequestType<{|
  uri: { companiesId: Array<Number> },
  query: { users: Array<Number> },
  headers: { customHeader: CustomAuth },
  cookie: { customCookie: CustomAuth }
|}>

type CustomAuth = { username: String, pass: String }

@OperationElement()
var getUsersByCompaniesIdEndpoint: HttpOperation<GetUsersByCompaniesIdEndpointRequest, Any, Any, HttpConnection> = {
  name: "getUserByIdEndpoint",
  displayName: "Get user by id",
  executor: (parameter, connection) ->
    success(connection({
      method: "GET",
      path: "/usersByCompaniesId/" ++ serializeUriParam(parameter.uri.companiesId, config: { style: "simple", explode: false }),
      queryParams: parameter.query update {
        case users at .users -> users <~ { style: "form", explode: true }
      },
      headers: parameter.headers update {
        case customHeader at .customHeader -> serializeHeaders(customHeader, config: { style: "simple", explode: false })
        case Cookie at .Cookie! -> serializeCookies(parameter.cookie update {
          case customCookie at .customCookie -> customCookie <~ { style: "form", explode: false }
        })
      }
    }) as HttpResponse<GetUsersByCompanyIdEndpointResponse>)
}
```

- **Query parameter encoding**

  To encode query parameters, add metadata to each parameter within the `queryParams` object of the
  HTTP request. The encoding is performed automatically before the request is sent.

  ```none
  queryParams: parameter.query update {
      case users at .users -> users <~ { style: "form", explode: true }
  }
  ```

- **URI/path parameter encoding**

  To encode URI parameters, call the `serializeUriParam` function for each parameter, passing the
  parameter and its encoding configuration.

  ```none
  path: "/usersByCompaniesId/" ++ serializeUriParam(parameter.uri.companiesId, config: { style: "simple", explode: false }),
  ```

- **Header and cookie encoding**

  To encode headers, call the `serializeHeaders` function for each header (except for the `Cookie`
  header), providing the parameter and encoding configuration. To encode cookies, call the
  `serializeCookies` function with the cookie object and encoding information for each parameter.

  ```none
  headers: parameter.headers update {
      case customHeader at .customHeader -> serializeHeaders(customHeader, config: {style: "simple", explode: false})
      case Cookie at .Cookie! -> serializeCookies(parameter.cookie update {
          case customCookie at .customCookie -> customCookie <~ { style: "form", explode: false }
      })
  }
  ```

### Operation Errors

Operations can fail in different ways, especially when interacting with HTTP endpoints that might
return various status codes.

This approach only signals that a failure occurred, without providing specific error kinds or
categories:

```none
var getUsers: Operation<{}, HttpResponse<{items: Array<{id: String, name: String, email: String}>, nextUrl?: String}>, ResultFailure<HttpResponse, Error>, HttpConnection> = {
  name: "getUsers",
  displayName: "Get Users",
  executor: (parameter, connection) -> do {
    var response = connection({method: 'GET', path: "/users"})
    ---
    if (response.status == 200)
      success(response as HttpResponse<{items: Array<{id: String, name: String, email: String}>, nextUrl?: String}>)
    else
      failure(response)
  }
}
```

#### Example: Error Types

To allow users to handle specific error types, such as `404 Not Found`, define error types and
return them accordingly:

```none
type Error404 = Error<"404", "CLIENT_ERROR">

var Error404Instance: Error404 = {
  kind: "404",
  categories: ["CLIENT_ERROR"]
}

var getUsers: Operation<{}, HttpResponse<{items: Array<{id: String, name: String, email: String}>, nextUrl?: String}>, ResultFailure<String, Error404 | Error>, HttpConnection> = {
  name: "getUsers",
  displayName: "Get Users",
  executor: (parameter, connection) -> do {
    var response = connection({method: 'GET', path: "/users"})
    ---
    if (response.status == 200)
      success(response)
    else if (response.status == 404)
      failure("404", Error404Instance)
    else
      failure("unknown error")
  }
}
```

With this pattern, users can distinguish and handle specific error kinds at runtime.

#### Example: Multiple Error Values

Some external systems return different error payloads for different error types. For example, `4XX`
and `5XX` return different messages:

```none
type Error404 = Error<"404", "CLIENT_ERROR">
var Error404Instance: Error404 = {
  kind: "404",
  categories: ["CLIENT_ERROR"]
}

type Error500 = Error<"500", "SERVER_ERROR">
var Error500Instance: Error500 = {
  kind: "500",
  categories: ["SERVER_ERROR"]
}

type 404ErrorMessage = {
  message: String
}

type 500ErrorMessage = {
  errorCode: Number
}

var getUsers: Operation<{}, HttpResponse<{items: Array<{id: String, name: String, email: String}>, nextUrl?: String}>, ResultFailure<404ErrorMessage, Error404> | ResultFailure<500ErrorMessage, Error500>, HttpConnection> = {
  name: "getUsers",
  displayName: "Get Users",
  executor: (parameter, connection) -> do {
    var response = connection({method: 'GET', path: "/users"})
    ---
    if (response.status == 200)
      success(response)
    else if (response.status == 404)
      failure({message: "404 Not Found"}, Error404Instance)
    else
      failure({errorCode: 500}, Error500Instance)
  }
}
```

In this example, a `4XX` error returns a `{message: String}` payload, while a `5XX` error returns
`{errorCode: Number}`. This allows users to handle and inspect error payloads based on the error
kind.

<!-- document id=2e2eb2a9af7c8db2bee73bef1da56dfbd45046694b447593148538d710b74420 url=/mulesoft/current/en-us/connector-builder/packaging-connectors.md -->

---
product: Connector Builder
version: master
---

# Packaging Connectors

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Learn how to package your connector. Packaging is the process of compiling and preparing your
connector for release.

You can package your connector via the UI, MCP tools, or the terminal.

## Package Connectors via the UI

1.  Open your IDE and go to **Connector Builder - Editor**.

2.  Click **Build Project**.

If the build completes successfully, a success message appears. If the build doesn’t complete
successfully, an error message appears. In either case, you can click **View output** to review the
output.

## Package Connectors with MCP Tools (Cursor)

1.  Open the Connector Builder extension in Cursor.

2.  Select **Settings** and ensure **Enable Mcp Tools** is enabled.

3.  Open the Cursor chat window (if not already open).

4.  Ask the agent to build the connector. For example, enter `Build this connector`. This calls the
    `uc_connector_lifecycle` MCP tool with `type='build'`, which runs `mvn install` using the
    extension’s bundled Maven.

5.  Enter the required inputs when prompted.

6.  Confirm your inputs. Connector Builder builds the connector.

For more information, see
[MuleSoft DX MCP Server Tool Reference](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools).

## Package Connectors via the Terminal

1.  Open your IDE and ensure that you have opened the root folder of your connector project.

    If necessary, go to **File** > **Open Folder** and select the appropriate folder. The Explorer
    view should display top-level items. Make sure you aren’t inside the `connectivity-model`,
    `anypoint-connector-model`, or `flow-connector-model` subfolders.

2.  Go to **Terminal** > **New Terminal**.

3.  In the terminal, run this command:

    mvn clean package

4.  Wait for the build process to complete. If the build completes successfully, an output similar
    to this appears:

    \[INFO\] ------------------------------------------------------------------------ \[INFO\]
    Reactor Summary for <your-connector-name> <version>: \[INFO\] \[INFO\] <your-connector-name>
    .............................. SUCCESS \[ x.xxx s\] \[INFO\]
    <your-connector-name>-connectivity-model ........... SUCCESS \[ x.xxx s\] \[INFO\]
    <your-connector-name>-flow-connector-model ......... SUCCESS \[ x.xxx s\] \[INFO\]
    ------------------------------------------------------------------------ \[INFO\] BUILD SUCCESS
    \[INFO\] ------------------------------------------------------------------------ \[INFO\] Total
    time: x.xxx s \[INFO\] Finished at: <timestamp> \[INFO\]
    ------------------------------------------------------------------------

    > [!NOTE] The names, numbers, and timestamps in the output will vary. The key indicator of a
    > successful build is the line: `BUILD SUCCESS`.

    If you don’t see `BUILD SUCCESS`, the build didn’t complete successfully. In this case, review
    the errors in the terminal output.

<!-- document id=f9af33894efb0245151a24abf2f67c55da3c9e62e1231ba4b0c9123e5879c65c url=/mulesoft/current/en-us/connector-builder/pagination.md -->

---
product: Connector Builder
version: master
---

# Pagination

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Learn how to define pagination for your connector. Pagination is the process of dividing a large
dataset into smaller subsets, called pages, to make it easier to manage and display.

You can define pagination using either the UI or LinkWeave. Use the UI as your primary approach, as
it significantly reduces manual development effort. Reserve LinkWeave for advanced scenarios that
require custom logic. With Connector Builder, the goal is to focus on reviewing and validating the
generated process, rather than writing custom code.

## Define Pagination Using the UI

You can define pagination without AI assistance, with AI assistance (available when using Cursor),
or with MCP tools (available when using Cursor).

### Define Pagination Without AI Assistance

To define pagination for a single operation:

1.  Under **Operations Explorer**, select the operation.

2.  Select **Add pagination**.

3.  Click **Generate Anypoint Connector** or **Generate Flow Connector** (or **Regenerate Project**
    if you’ve already generated the connector). To enable the pagination feature, you must
    regenerate the connector where the paginated operations will be used. If you skip this step, the
    paginated operations will only exist in the underlying model and won’t be available in the
    connector itself.

To define pagination for multiple operations:

1.  Under **Project Settings**, select **Pagination**.

2.  Under **Configure Pagination for Multiple Operations**, select the operations to configure
    pagination for.

3.  Click **Generate Anypoint Connector** or **Generate Flow Connector** (or **Regenerate Project**
    if you’ve already generated the connector). To enable the pagination feature, you must
    regenerate the connector where the paginated operations will be used. If you skip this step, the
    paginated operations will only exist in the underlying model and won’t be available in the
    connector itself.

### Define Pagination With AI Assistance (Cursor)

1.  Ensure **Enable Ai Assisted Workflows** is enabled.

2.  Under **Operations Explorer**, select the operation.

3.  Click **Add pagination**, then click **Help me with this**. This copies a prepared prompt to
    your clipboard, which you can manually paste into the Cursor chat window.

4.  Open the Cursor chat window (if not already open) and paste the copied prompt. Ensure you’re in
    Agent mode. If the API documentation or API specification isn’t already included in the prompt,
    provide it now.

    The agent analyzes the provided resources, suggests a pagination strategy, and recommends
    parameters.

5.  Review the suggested pagination strategy and fill in the parameters as recommended.

6.  Click **Apply**. Connector Builder generates a paginated operation.

### Define Pagination with MCP Tools (Cursor)

1.  Open the Connector Builder extension in Cursor.

2.  Select **Settings** and ensure **Enable Mcp Tools** is enabled.

3.  Open the Cursor chat window (if not already open).

4.  Ask the agent to add pagination. For example, enter `Add pagination to this operation`. This
    calls the `uc_add_pagination` MCP tool, which adds pagination to the operation.

5.  Enter the required inputs when prompted.

6.  Confirm your inputs. Connector Builder generates paginated operations.

For more information, see
[MuleSoft DX MCP Server Tool Reference](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools).

## Define Pagination Using LinkWeave

You can define pagination for an operation by decorating it with a pagination strategy. The
decorated operation returns results of type `Page`.

Connector Builder supports these pagination strategies.

- [Page Number Pagination](#page-number-pagination)

- [Offset Pagination](#offset-pagination)

- [Marker Pagination](#marker-pagination)

- [Hypermedia Pagination](#hypermedia-pagination)

### Page Number Pagination

Page number pagination is a strategy for APIs that use a query parameter to specify the page number,
for example, `?page=2`.

Suppose your API endpoint is `http://www.mulesoft.com/users?page=X`.

Define the operation:

```none
var getUsers : Operation<{page: Number}, HttpResponse<{items: Array<{id: String, name: String, email: String}>}>, ResultFailure<HttpResponse, Error>, HttpConnection> = {
    name: "getUsers",
    displayName: "Get Users",
    executor: (parameter, connection) -> do {
        var response = connection({method: 'GET', path: "/users?page=" ++ parameter.page})
        ---
        if (response.status == 200)
          success(response as HttpResponse<{items: Array<{id: String, name: String, email: String}>}>)
        else
          failure(response)
    }
}
```

Decorate it for pagination:

```none
@OperationElement()
var getUsersPaginated = pageNumberPaginated(
  getUsers,
  (page) -> page.body.items default [],
  (param) -> param.page default 0,
  (param, pageNumber) -> (param update { case page at .page! -> pageNumber })
)
```

### Offset Pagination

Offset pagination is a strategy for APIs that use an offset parameter to indicate the starting point
of results, for example, `?offset=10&limit=20`.

Suppose your API endpoint is `http://www.mulesoft.com/users?offset=X&limit=Y`.

Define the operation:

```none
var getUsers : Operation<{from: Number, limit: Number}, HttpResponse<{items: Array<{id: String, name: String, email: String}>}>, ResultFailure<HttpResponse, Error>, HttpConnection> = {
    name: "getUsers",
    displayName: "Get Users",
    executor: (parameter, connection) -> do {
        var response = connection({method: 'GET', path: "/users?from=" ++ parameter.from ++ "&limit=" ++ parameter.limit})
        ---
        if (response.status == 200)
          success(response as HttpResponse<{items: Array<{id: String, name: String, email: String}>}>)
        else
          failure(response)
    }
}
```

Decorate it for pagination:

```none
@OperationElement()
var getUsersPaginated = offsetPaginated(
  getUsers,
  (page) -> page.body.items default [],
  (param) -> param.from default 0,
  (param, offset) -> (param update { case from at .from! -> offset })
)
```

### Marker Pagination

Marker pagination is a strategy for APIs that use a marker or token to indicate the position in the
dataset, for example, `?markerToken=abc123&limit=20`.

Suppose your API endpoint is `http://www.mulesoft.com/users?markerToken=X&limit=Y`.

Define the operation:

```none
var getUsers : Operation<{markerToken?: String, limit: Number}, HttpResponse<{items: Array<{id: String, name: String, email: String}>, markerToken?: String}>, ResultFailure<HttpResponse, Error>, HttpConnection> = {
    name: "getUsers",
    displayName: "Get Users",
    executor: (parameter, connection) -> do {
        var markerParams = if (!isEmpty(parameter.markerToken))
            ("?markerToken=" ++ parameter.markerToken! ++ "&limit=" ++ parameter.limit)
            else ("?limit=" ++ parameter.limit)
        var response = connection({method: 'GET', path: "/users" ++ markerParams})
        ---
        if (response.status == 200)
          success(response as HttpResponse<{items: Array<{id: String, name: String, email: String}>, markerToken?: String}>)
        else
          failure(response)
    }
}
```

Decorate it for pagination:

```none
@OperationElement()
var getUsersPaginated = markerPaginated(
  getUsers,
  (page) -> page.body.items default [],
  (page) -> page.body.markerToken default "",
  (param, marker) -> (param update { case markerToken at .markerToken! -> marker })
)
```

If you want to expose only a subset of the input parameters, for example, only `limit`, you can use
`mapInputOperation`:

```none
// Expose only 'limit' as input, but propagate markerToken internally
var getUsersPaginatedCustom = getUsersPaginated mapInputOperation (param: {limit: Number}) -> param
```

### Hypermedia Pagination

Hypermedia pagination is a strategy for APIs that provide the URL for the next page in the response
body or headers. This strategy is supported when the next URL shares the same host and path as the
current URL but with different query parameters, for example,
`http://www.mulesoft.com/users?pageMarker=X&limit=Y` and the response body contains a `nextUrl`
field.

#### Same Endpoint for All Pages

Suppose your API endpoint is `http://www.mulesoft.com/users?pageMarker=X&limit=Y` and the response
body contains a `nextUrl` field.

Define the operation:

```none
var getUsers : Operation<{pageMarker?: String, limit?: Number}, HttpResponse<{items: Array<{id: String, name: String, email: String}>, nextUrl?: String}>, ResultFailure<HttpResponse, Error>, HttpConnection> = {
    name: "getUsers",
    displayName: "Get Users",
    executor: (parameter, connection) -> do {
        var response = connection({method: 'GET', path: "/users?pageMarker=" ++ (parameter.pageMarker default "") ++ "&limit=" ++ (parameter.limit default "")})
        ---
        if (response.status == 200)
          success(response as HttpResponse<{items: Array<{id: String, name: String, email: String}>, nextUrl?: String}>)
        else
          failure(response)
    }
}
```

Decorate it for pagination:

```none
@OperationElement()
var getUsersPaginated = hypermediaPaginated(
   getUsers,
   (page) -> page.body.items default [],
   (page) -> page.body.nextUrl default "",
   (param, nextUrl) -> parseQueryParameters(nextUrl)
)
```

If your operation input is a complex object, you can adjust the last lambda accordingly:

```none
type OperationInputType = {uri: Object, query: Object}

@OperationElement()
var getUsersPaginated = hypermediaPaginated(
   getUsers,
   (page) -> page.body.items default [],
   (page) -> page.body.nextUrl default "",
   (param, nextUrl) -> {uri: param.uri, query: parseQueryParameters(nextUrl)}
)
```

#### Different Endpoint for Next Page

Suppose your API uses two endpoints and the response body contains a `nextUrl` field.

- First page: `http://www.mulesoft.com/users`

- Next pages: `http://www.mulesoft.com/more/{queryLocator}`

Define the operations:

```none
var getUsers : Operation<{}, HttpResponse<{items: Array<{id: String, name: String, email: String}>, nextUrl?: String}>, ResultFailure<HttpResponse, Error>, HttpConnection> = {
    name: "getUsers",
    displayName: "Get Users",
    executor: (parameter, connection) -> do {
        var response = connection({method: 'GET', path: "/users"})
        ---
        if (response.status == 200)
          success(response as HttpResponse<{items: Array<{id: String, name: String, email: String}>, nextUrl?: String}>)
        else
          failure(response)
    }
}

var getMore : Operation<{queryLocator: String}, HttpResponse<{items: Array<{id: String, name: String, email: String}>, nextUrl?: String}>, ResultFailure<HttpResponse, Error>, HttpConnection> = {
    name: "getMore",
    displayName: "Get More",
    executor: (parameter, connection) -> do {
        var response = connection({method: 'GET', path: "/more/" ++ parameter.queryLocator})
        ---
        if (response.status == 200)
          success(response as HttpResponse<{items: Array<{id: String, name: String, email: String}>, nextUrl?: String}>)
        else
          failure(response)
    }
}
```

Decorate them for pagination:

```none
// Paginate the 'getMore' operation
var getMorePaginated = getMore paginated (param, page) -> {
    items: page.body.items default [],
    (nextPage: {
        args: {queryLocator: (splitBy(page.body.nextUrl, "/")[-1] default "")}
    }) if (!isEmpty(page.body.items) and !isEmpty(page.body.nextUrl))
}

// Use 'paginatedWithNextPageOp' to combine the first and next-page operations
var getUsersPaginated = paginatedWithNextPageOp(getUsers, getMorePaginated, (param, page) -> {
    items: page.body.items default [],
    (nextPage: {
        args: {queryLocator: (splitBy(page.body.nextUrl, "/")[-1] default "")}
    }) if (!isEmpty(page.body.items) and !isEmpty(page.body.nextUrl))
})
```

<!-- document id=2e4b5ec5b0ff149551d6d1c348364ade043aa26130c54d787dc9da3e7c9d4af7 url=/mulesoft/current/en-us/connector-builder/releasing-connectors.md -->

---
product: Connector Builder
version: master
---

# Releasing Connectors

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Learn how to release your connector. Releasing is the process of making your connector available to
others.

Connector Builder supports releasing your connector to Anypoint Platform and to Salesforce Flow.

## Release Connectors to Anypoint Platform

To make your connector available on Anypoint Platform, release it to Anypoint Exchange. Connector
Builder supports private releases to Anypoint Exchange only. The connector can still be shared with
other accounts or teams.

After you release your connector, you should see your published connector in Anypoint Exchange. If
you’re unable to see the published connector, click **Back to legacy search** to switch the search
mode. For more information about publishing to Exchange, see
[Publishing Assets Using Maven](https://docs.mulesoft.com/exchange/to-publish-assets-maven).

### Release Connectors to Anypoint Platform Using the UI

1.  Open your IDE and go to **Connector Builder - Editor**.

2.  Click **Publish…​**.

3.  In the UI, complete all checklist items to ensure you meet the release requirements.

4.  Click **Publish to Anypoint Exchange**. This runs `mvn deploy` from the
    `{projectname}-anypoint-connector-model` directory.

### Release Connectors to Anypoint Platform with MCP Tools (Cursor)

1.  Open the Connector Builder extension in Cursor.

2.  Select **Settings** and ensure **Enable Mcp Tools** is enabled.

3.  Open the Cursor chat window (if not already open).

4.  Ask the agent to release the connector. For example, enter
    `Publish this connector to Anypoint Exchange`. This calls the `uc_connector_lifecycle` MCP tool
    with `type='publish'`, which releases the connector to Anypoint Exchange. The same tool with
    `type='build'` builds the connector locally.

5.  Enter the required inputs when prompted.

6.  Confirm your inputs. Connector Builder releases the connector to Anypoint Exchange.

For more information, see
[MuleSoft DX MCP Server Tool Reference](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools).

## Release Connectors to Salesforce Flow

You can deliver a custom Flow connector in two ways:

- Publish to AgentExchange as a standalone connector listing

  Package the connector as its own managed 2GP solution. Submit the AgentExchange Security Review.
  Then list it publicly on AgentExchange, or distribute it privately by sharing a direct package
  URL.

- Deploy to a single customer org

  A Salesforce customer can build a custom connector and deploy it directly to their own org. No
  AgentExchange listing is required.

In both cases, the connector runs in the customer org and requires the MuleSoft for Flow add-on.
Each connector operation consumes Automation Credits.

### Release Connectors to AgentExchange

1.  Package Your Connector as a Standalone Managed 2GP Solution

    Package your custom connector as a standalone 2GP managed package, one package per connector,
    with no other app content. This is the format AgentExchange requires for distribution and
    installation in subscriber orgs. For more information, see
    [Package a Custom Flow Connector as a 2GP Managed Package](https://developer.salesforce.com/docs/atlas.en-us.pkg2_dev.meta/pkg2_dev/dev2gp_package_custom_flow_connector.htm).

2.  Check Listing Readiness

    Before submitting your custom Flow connector for security review, verify that your package
    version is ready to be listed. For more information, see
    [Security Requirements for AppExchange Partners and Solutions](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/security_review_create_secure_solution.htm).

3.  Pass the AgentExchange Security Review

    Your custom Flow connector must pass the AgentExchange Security Review before it gets listed on
    AgentExchange. This applies to both public AgentExchange listings and private listings
    distributed by direct package URL. For more information, see
    [Pass the AgentExchange Security Review](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/security_review_guidelines.htm).

4.  Create and Publish Your AgentExchange Listing

    After your custom connector package passes security review, create the listing in Partner
    Console. For more information, see
    [Manage Your AppExchange Listings](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/packaging_distributing.htm).

5.  Maintain and Update Your Connector

    If you revise a published custom connector, update your AppExchange listing so that customers
    get access to the latest version. For more information, see
    [Manage Your Published Listings](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/appexchange_manage_published_listings_intro.htm).

### Release Connectors Directly to a Salesforce Org

To deploy a Flow connector directly to a Salesforce org, deploy the connector JAR as an
`IntegArtifactDef` metadata component using Salesforce CLI. This is the Flow connector JAR produced
from [Packaging Connectors](https://docs.mulesoft.com/connector-builder/packaging-connectors). The JAR file name follows the pattern
`{projectname}-flow-connector-model-{version}-dw-library.jar`.

1.  Log in to your org from Salesforce CLI:

    sf org login web -r <org-url>

    > [!NOTE] Lightning URLs are not supported.

2.  Generate a Salesforce project to host the connector metadata:

    sf project generate --output-dir my-workspace --name my-project

3.  In `my-workspace/my-project/sfdx-project.json`, set `"sourceApiVersion": "66.0"`.

4.  Inside the project folder, create a folder for the connector under
    `force-app/main/default/integArtifactDefs/`:

    mkdir -p force-app/main/default/integArtifactDefs/<ConnectorName>/

5.  Inside that folder, create a `<ConnectorName>-meta.xml` file:

    ```xml
    <?xml version="1.0" encoding="UTF-8"?>
    <IntegArtifactDef xmlns="http://soap.sforce.com/2006/04/metadata" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <description>{description}</description>
        <displayName>{displayName}</displayName>
        <groupId>{groupId}</groupId>
    </IntegArtifactDef>
    ```

6.  Create a versioned subfolder for the connector JAR and place the JAR inside it:

    mkdir -p force-app/main/default/integArtifactDefs/<ConnectorName>/<VersionString>/

7.  Deploy the connector to the org:

    sf project deploy start -m "IntegArtifactDef:<ConnectorName>" --target-org <your-org-username>

<!-- document id=c11b9d0c974ef25f37af20778ef79a13d522c56daebe082c798dda748b99e723 url=/mulesoft/current/en-us/connector-builder/running-connectors.md -->

---
product: Connector Builder
version: master
---

# Running Connectors

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Learn how to run your connector. Running a connector involves configuring and deploying the
connector.

Connector Builder supports running your connector in Anypoint Platform and in Salesforce Flow.

## Run Connectors in Anypoint Platform

You can run a connector in Anypoint Studio or Anypoint Code Builder.

### Run Connectors in Anypoint Studio

1.  [Configure your connector in Anypoint Studio](https://docs.mulesoft.com/connectors/introduction/intro-config-use-studio).

2.  [Deploy your connector in Anypoint Studio](https://docs.mulesoft.com/studio/deploy-mule-application-task).

### Run Connectors in Anypoint Code Builder

1.  [Configure your connector in Anypoint Code Builder](https://docs.mulesoft.com/connectors/introduction/intro-config-use-acb).

2.  [Deploy your connector in Anypoint Code Builder](https://docs.mulesoft.com/anypoint-code-builder/int-deploy-mule-apps).

## Run Connectors in Salesforce Flow

After you
[release your connector to Salesforce Flow](https://docs.mulesoft.com/connector-builder/releasing-connectors#release-connectors-to-salesforce-flow),
the connector appears under **Automation** > **Integrations** in the org and is available as an
action in Flow Builder.

<!-- document id=c5352f8557b57ddaf6963c40a3be169a54552541e4225cdb708abbe908a10f4b url=/mulesoft/current/en-us/connector-builder/telemetry.md -->

---
product: Connector Builder
version: master
---

# Telemetry in Connector Builder

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Connector Builder can send a small amount of usage telemetry that helps Salesforce understand which
features are most useful and where to invest. It’s limited to product-usage signals and doesn’t
collect the content you work on.

Telemetry runs in the background and never affects your work. If Connector Builder can’t collect or
send telemetry for any reason, Connector Builder skips it and continues normally.

## Telemetry Data

This table shows what Connector Builder reports and what it doesn’t.

<table><colgroup><col> <col></colgroup><thead><tr><th>What Connector Builder Reports</th><th>What Connector Builder Doesn’t Collect</th></tr></thead><tbody><tr><td><div><div><ul><li><p>That a connector project was successfully created.</p></li><li><p>Where you started the action: the Connector Builder UI in VS Code or the <code>uc_generate_connector</code> MCP tool. Connector Builder records this as a category, not free-form text.</p></li><li><p>The installed version of the Connector Builder extension, so that Salesforce can understand usage for each release.</p></li></ul></div></div></td><td><div><div><ul><li><p>Source code or connector definitions, including generated project contents and draft project contents beyond how the project was started.</p></li><li><p>API specification contents, including source code, schemas, and examples.</p></li><li><p>Names and identifiers from your project, including connector names, vendor names, package names, and group IDs.</p></li><li><p>API endpoint URLs written into the generated project.</p></li><li><p>File or folder paths, including project, workspace, and output locations.</p></li><li><p>Personal, company, or account identifiers, including your identity, your Salesforce org, your user account, and your machine.</p></li><li><p>Credentials or secrets, including tokens, keys, and passwords.</p></li><li><p>Error details or free-form text, including error messages, stack traces, log output, and text that you type.</p></li></ul></div></div></td></tr></tbody></table>

Connector Builder counts only successful actions. If a project isn’t created because the operation
fails or is interrupted, Connector Builder reports nothing. It doesn’t count attempts or failures as
usage.

## Enable or Disable Telemetry

Connector Builder follows the standard VS Code telemetry setting (`telemetry.telemetryLevel`) and
checks it before sending anything. Connector Builder has no separate telemetry switch, so this
setting is the single control. To enable or disable telemetry, set the telemetry level to one of
these values:

- `off`: Connector Builder sends nothing.

- `crash`, `error`, or `all`: VS Code sends increasingly detailed telemetry. Connector Builder sends
  its usage signals at any of these levels.

Set the telemetry level in the Settings UI or in `settings.json`. The change applies immediately.
You don’t need to reload or restart VS Code. For more information, see the
[VS Code telemetry documentation](https://code.visualstudio.com/docs/configure/telemetry).

### Use the Settings UI

1.  Go to VS Code Settings.

2.  Search for `Telemetry`.

3.  Set **Telemetry: Telemetry Level** to your preferred value.

### Use settings.json

To set the telemetry level in `settings.json`, add the `telemetry.telemetryLevel` property:

```json
{
  "telemetry.telemetryLevel": "off"
}
```

<!-- document id=c5033f994c080be2b8f7593f53d9b81cc0baf8ba6775f59735b5a64b03e97bce url=/mulesoft/current/en-us/connector-builder/terms-of-use.md -->

---
product: Connector Builder
version: master
---

# Terms of Use for Connector Builder

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

This Extension is subject to the terms of your Main Services Agreement with Salesforce.

If you do not have a Main Services Agreement in place with Salesforce, by downloading this Extension
you agree to the terms of the Main Services Agreement (the “Agreement”) found
[here](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Salesforce_MSA.pdf)
and acknowledge that if you are accepting this Agreement on behalf of a company or other legal
entity, you have the authority to bind such entity and affiliates to the Agreement.

This Extension may include some services that are in beta. These beta services are subject to the
Beta Services Terms at [Agreements - Salesforce.com](https://www.salesforce.com/company/legal/) or a
written Unified Pilot Agreement if executed by Customer, and applicable terms in the
[Product Terms Directory](https://ptd.salesforce.com/?_ga=2.247987783.1372150065.1709219475-629000709.1639001992).
Use of any beta services is at the Customer’s sole discretion.

Generative AI can produce inaccurate or harmful responses. Review the output for accuracy and
safety. You assume responsibility for how the outcomes are applied to your organization.

<!-- document id=6be30dda02ccc316517d7ccf6ec286f90fe8b500b6b27957bbf6b307eca5594a url=/mulesoft/current/en-us/connector-builder/testing-connectors.md -->

---
product: Connector Builder
version: master
---

# Testing Connectors

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Learn how to test your connector. Testing is an important part of the development process, and it
helps you ensure that your connector works as expected. Testing your connector involves generating
tests, running tests, and validating the connector within the platform.

## Generate Tests (Beta)

> [!NOTE] Generating tests is a pilot or beta service that is subject to the Beta Services Terms at
> [Agreements - Salesforce.com](https://www.salesforce.com/company/legal/) or a written Unified
> Pilot Agreement if executed by Customer, and applicable terms in the
> [Product Terms Directory](https://ptd.salesforce.com/?_ga=2.247987783.1372150065.1709219475-629000709.1639001992).
> Use of this pilot or beta service is at the Customer’s sole discretion.

You can generate tests without AI assistance, with AI assistance (available when using Cursor), or
with MCP tools (available when using Cursor). Tests are generated for the modules present in your
connector project: the connectivity model (CCM), the Anypoint connector module (ACM), and the Flow
connector module (FCM). Tests are split into data files and actual test files, creating a structured
project. These tests include:

- **Tests for all use cases**: This includes basic connectivity model, Anypoint Connector, and Flow
  Connector tests, pagination tests, and negative test cases.

- **Mock server for negative test cases**: A mock server is used for negative test cases because
  replicating them against a live server is not always feasible.

- **Reusable test data**: Test data is stored in separate files for easy reuse.

- **Self-contained tests for connector operations**: These tests function independently. For
  example, if a connector has `POST`, `GET`, `PATCH`, and `DELETE` operations for `/invoices`, a
  self-contained test case can be generated, and the report reflects this.

Here’s an example of a generated test file for `/calendars/{calendarId}/acl/{ruleId} - PATCH` in a
Google Calendar connector, which demonstrates the generation of parent operations, rule creation,
and resource deletion:

```none
%dw 2.8
import * from dw::test::Asserts
import * from dw::test::Tests
import * from dw::Runtime
import * from com::mulesoft::connectivity::Model
import * from com::mulesoft::connectivity::transport::Http
import * from com::mulesoft::connectivity::Metadata

import * from utils::ConnectionOperations

import * from com::mulesoft::connectivity::zzz4::operations::O_calendars_post
import * from com::mulesoft::connectivity::zzz4::operations::O_calendars__calendarId__get
import * from com::mulesoft::connectivity::zzz4::operations::O_calendars__calendarId__patch
import * from com::mulesoft::connectivity::zzz4::operations::O_calendars__calendarId__delete
import * from com::mulesoft::connectivity::zzz4::operations::O_calendars__calendarId__acl_post
import * from com::mulesoft::connectivity::zzz4::operations::O_calendars__calendarId__acl_get
import * from com::mulesoft::connectivity::zzz4::operations::O_calendars__calendarId__acl__ruleId__get
import * from com::mulesoft::connectivity::zzz4::operations::O_calendars__calendarId__acl__ruleId__patch
import * from com::mulesoft::connectivity::zzz4::operations::O_calendars__calendarId__acl__ruleId__delete
import * from data::calendars_post_request
import * from data::calendars__calendarId__get_request
import * from data::calendars__calendarId__patch_request
import * from data::calendars__calendarId__delete_request
import * from data::calendars__calendarId__acl_post_request
import * from data::calendars__calendarId__acl_get_request
import * from data::calendars__calendarId__acl__ruleId__get_request
import * from data::calendars__calendarId__acl__ruleId__patch_request
import * from data::calendars__calendarId__acl__ruleId__delete_request

var V_calendars_post_response = O_calendars_post.executor(V_calendars_post_request(), connection)

var V_calendars__calendarId__get_response = O_calendars__calendarId__get.executor(V_calendars__calendarId__get_request(CALENDARID), connection)

var V_calendars__calendarId__patch_response = O_calendars__calendarId__patch.executor(V_calendars__calendarId__patch_request(CALENDARID), connection)

var V_calendars__calendarId__delete_response = O_calendars__calendarId__delete.executor(V_calendars__calendarId__delete_request(CALENDARID), connection)

var V_calendars__calendarId__acl_post_response = O_calendars__calendarId__acl_post.executor(V_calendars__calendarId__acl_post_request(CALENDARID), connection)

var V_calendars__calendarId__acl_get_response = O_calendars__calendarId__acl_get.executor(V_calendars__calendarId__acl_get_request(CALENDARID), connection)

var V_calendars__calendarId__acl__ruleId__get_response = O_calendars__calendarId__acl__ruleId__get.executor(V_calendars__calendarId__acl__ruleId__get_request(CALENDARID,RULEID), connection)

var V_calendars__calendarId__acl__ruleId__patch_response = O_calendars__calendarId__acl__ruleId__patch.executor(V_calendars__calendarId__acl__ruleId__patch_request(CALENDARID,RULEID), connection)

var V_calendars__calendarId__acl__ruleId__delete_response = O_calendars__calendarId__acl__ruleId__delete.executor(V_calendars__calendarId__acl__ruleId__delete_request(CALENDARID,RULEID), connection)
---
"/calendars/{calendarId}/acl/{ruleId} tests" describedBy [
    "/calendars - POST Successful Execution" in do {
        V_calendars_post_response.value.status must equalTo(200)
    },
    "/calendars/{calendarId} - GET Successful Execution" in do {
        V_calendars__calendarId__get_response.value.status must equalTo(200)
    },
    "/calendars/{calendarId} - PATCH Successful Execution" in do {
        V_calendars__calendarId__patch_response.value.status must equalTo(200)
    },
    "/calendars/{calendarId} - DELETE Successful Execution" in do {
        V_calendars__calendarId__delete_response.value.status must equalTo(200)
    },
    "/calendars/{calendarId}/acl - POST Successful Execution" in do {
        V_calendars__calendarId__acl_post_response.value.status must equalTo(200)
    },
    "/calendars/{calendarId}/acl - GET Successful Execution" in do {
        V_calendars__calendarId__acl_get_response.value.status must equalTo(200)
    },
    "/calendars/{calendarId}/acl/{ruleId} - GET Successful Execution" in do {
        V_calendars__calendarId__acl__ruleId__get_response.value.status must equalTo(200)
    },
    "/calendars/{calendarId}/acl/{ruleId} - PATCH Successful Execution" in do {
        V_calendars__calendarId__acl__ruleId__patch_response.value.status must equalTo(200)
    },
    "/calendars/{calendarId}/acl/{ruleId} - DELETE Successful Execution" in do {
        V_calendars__calendarId__acl__ruleId__delete_response.value.status must equalTo(200)
    },
]
```

If any operation is missing, a self-sustained test case can’t be generated, and the report indicates
this. Here’s an example of a report for Google Calendar connector operations, which illustrates the
status (`SUCCESS` and `PARTIAL_SUCCESS`) and messages indicating missing operations or complete test
generation. This report is generated with the generated tests:

OPERATION NAME STATUS MESSAGE
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

calendar.calendars.delete SUCCESS Complete test generated calendar.calendarList.patch SUCCESS
Complete test generated calendar.calendarList.insert PARTIAL\_SUCCESS Missing DELETE operation -
Self sustained testcase not generated - Resource DELETION needed calendar.calendarList.list
PARTIAL\_SUCCESS Missing DELETE operation - Self sustained testcase not generated - Resource
DELETION needed calendar.events.get SUCCESS Complete test generated calendar.calendarList.update
SUCCESS Complete test generated calendar.events.list SUCCESS Complete test generated
calendar.colors.get PARTIAL\_SUCCESS Missing CREATE and DELETE operation - Self sustained testcase
not generated - Both Resource CREATION and DELETION needed calendar.acl.update SUCCESS Complete test
generated calendar.calendarList.get SUCCESS Complete test generated calendar.acl.list SUCCESS
Complete test generated calendar.calendars.update SUCCESS Complete test generated
calendar.calendarList.delete SUCCESS Complete test generated calendar.events.move SUCCESS Complete
test generated calendar.events.insert SUCCESS Complete test generated calendar.freebusy.query
PARTIAL\_SUCCESS Missing DELETE operation - Self sustained testcase not generated - Resource
DELETION needed calendar.calendarList.watch PARTIAL\_SUCCESS Missing DELETE operation - Self
sustained testcase not generated - Resource DELETION needed calendar.acl.delete SUCCESS Complete
test generated calendar.calendars.clear SUCCESS Complete test generated calendar.events.watch
SUCCESS Complete test generated calendar.settings.watch PARTIAL\_SUCCESS Missing DELETE operation -
Self sustained testcase not generated - Resource DELETION needed calendar.events.patch SUCCESS
Complete test generated calendar.settings.get PARTIAL\_SUCCESS Missing CREATE and DELETE operation -
Self sustained testcase not generated - Both Resource CREATION and DELETION needed
calendar.acl.watch SUCCESS Complete test generated calendar.calendars.patch SUCCESS Complete test
generated calendar.calendars.get SUCCESS Complete test generated calendar.calendars.insert
PARTIAL\_SUCCESS Missing DELETE operation - Self sustained testcase not generated - Resource
DELETION needed calendar.channels.stop PARTIAL\_SUCCESS Missing DELETE operation - Self sustained
testcase not generated - Resource DELETION needed calendar.settings.list PARTIAL\_SUCCESS Missing
CREATE and DELETE operation - Self sustained testcase not generated - Both Resource CREATION and
DELETION needed calendar.acl.patch SUCCESS Complete test generated calendar.events.delete SUCCESS
Complete test generated calendar.events.update SUCCESS Complete test generated calendar.acl.get
SUCCESS Complete test generated calendar.acl.insert SUCCESS Complete test generated
calendar.events.quickAdd SUCCESS Complete test generated calendar.events.import SUCCESS Complete
test generated calendar.events.instances SUCCESS Complete test generated

### Generate Tests Without AI Assistance

If you generate tests without AI assistance, the test data will have placeholder data.

1.  Open your IDE and go to **Connector Builder - Editor**.

2.  If you haven’t generated your connector yet, click **Generate** > **Generate Anypoint
    Connector** or **Generate** > **Generate Flow Connector**.

3.  Click **Generate** > **Generate Tests**. The available modules appear, with a dropdown for each.
    CCM is always available. ACM appears when an Anypoint connector module exists, and FCM appears
    when a Flow connector module exists.

4.  For each available module, select the connection type. You can:

    - Use a real connection to the API (requires a connection profile). See
      [Use Connection Profiles](https://docs.mulesoft.com/connector-builder/connections#use-connection-profiles).

    - Use a mocked connection (no authentication required).

    - Skip test generation for that module.

5.  Click **Generate Tests**. Tests are generated for each module according to the configuration you
    selected.

### Generate Tests With AI Assistance (Cursor)

If you generate tests with AI assistance, AI helps generate test data.

1.  Ensure **Enable Ai Assisted Workflows** is enabled.

2.  Open your IDE and go to **Connector Builder - Editor**.

3.  If you haven’t generated your connector yet, click **Generate** > **Generate Anypoint
    Connector** or **Generate** > **Generate Flow Connector**.

4.  Click **Generate** > **Generate Tests**. The available modules appear, with a dropdown for each.
    CCM is always available. ACM appears when an Anypoint connector module exists, and FCM appears
    when a Flow connector module exists.

5.  For each available module, select the connection type. You can:

    - Use a real connection to the API (requires a connection profile). See
      [Use Connection Profiles](https://docs.mulesoft.com/connector-builder/connections#use-connection-profiles).

    - Use a mocked connection (no authentication required).

    - Skip test generation for that module.

6.  In **Developer Documentation URL**, enter the URL that will be used as the source for the AI
    test data generation.

7.  Click **Help me with test data generation**. This copies a prepared prompt to your clipboard,
    which you can manually paste into the Cursor chat window.

8.  Open the Cursor chat window (if not already open) and paste the copied prompt. Ensure you’re in
    Agent mode.

    The agent analyzes the provided resources, and generates semantically accurate data for existing
    tests.

### Generate Tests With MCP Tools (Cursor)

1.  Open the Connector Builder extension in Cursor.

2.  Select **Settings** and ensure **Enable Mcp Tools** is enabled.

3.  Open the Cursor chat window (if not already open).

4.  Ask the agent to check what tests can be generated. For example, enter
    `What can I generate tests for here?`. This calls the `uc_get_test_generation_info` MCP tool,
    which returns the available modules (CCM, ACM, FCM) and reports whether tests already exist.

5.  If existing tests are reported, confirm whether to overwrite them. Existing test files are
    deleted when overwrite is confirmed.

6.  For each module you want to test, tell the agent whether to use a mocked connection or a real
    connection. For real connections, you need a connection profile ID, so use the
    `uc_list_connection_profiles` MCP tool first to
    [list connection profiles](https://docs.mulesoft.com/connector-builder/connections#list-connection-profiles-with-mcp-tools) to retrieve the
    ID.

7.  Confirm your inputs. This calls the `uc_generate_tests` MCP tool, which generates tests for the
    selected modules.

For more information, see
[MuleSoft DX MCP Server Tool Reference](https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools).

## Run Tests

You can run tests without or with AI assistance (available when using Cursor). If you use AI
assistance, you can make your generated test data semantically accurate. If you don’t use AI
assistance, the data is only schematically accurate and requires manual effort.

### Run Tests Without AI Assistance

1.  Manually edit data files to provide relevant data for test cases.

2.  To resolve failed tests, log the response to debug issues, for example:

    var V\_calendars\_\_calendarId\_\_acl\_get\_response =
    log(O\_calendars\_\_calendarId\_\_acl\_get.executor(V\_calendars\_\_calendarId\_\_acl\_get\_request(CALENDARID),
    connection))

3.  Run tests by using the `mvn test` command.

### Run Tests With AI Assistance (Cursor)

1.  Ensure **Enable Ai Assisted Workflows** is enabled.

2.  A rule file is generated to assist you in creating test data, at
    `<project root>/.cursor/rules/test-data-generation-rules`.

3.  Open the Cursor chat window and ask the agent to create sample test data according to the
    generated rule file, referring to SaaS documentation as needed.

4.  To resolve failed tests, log the response to debug issues, for example:

    var V\_calendars\_\_calendarId\_\_acl\_get\_response =
    log(O\_calendars\_\_calendarId\_\_acl\_get.executor(V\_calendars\_\_calendarId\_\_acl\_get\_request(CALENDARID),
    connection))

5.  Run tests by using the `mvn test` command.

## Validate the Connector

Before you release your connector, you can install the connector in the platform to make sure it
works as expected.

### Validate the Connector in Anypoint Platform

To validate the connector in Anypoint Platform, you can install the connector in Anypoint Studio or
Anypoint Code Builder.

1.  In the `pom.xml` file, ensure `mule-maven-plugin-version` is 4.6.0 or later.

2.  In the `pom.xml` file, add your connector dependency, for example:

    <dependencies>
     <dependency>
      <groupId>com.mulesoft.connectivity.flights</groupId>
      <artifactId>flights-anypoint-connector-model</artifactId>
      <version>0.0.3-SNAPSHOT</version>
      <classifier>mule-plugin</classifier>
     </dependency>
    </dependencies>

Now, your connector appears in Anypoint Studio or Anypoint Code Builder and you can test the
connector functionality.

<!-- document id=cd080a7ff73a2571f9672ae556c6a465f7b47550b33c08750eaf156b619b9282 url=/mulesoft/current/en-us/connector-builder/triggers.md -->

---
product: Connector Builder
version: master
---

# Triggers

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Learn how to define triggers for your connector. A trigger is a function that is automatically
executed in response to specific events. For example, when a new contact is created, you can trigger
an operation to send an email to the contact. Triggers help automate business processes by
eliminating manual intervention.

You can define triggers using either the UI or LinkWeave. Use the UI as your primary approach, as it
significantly reduces manual development effort. Reserve LinkWeave for advanced scenarios that
require custom logic. With Connector Builder, the goal is to focus on reviewing and validating the
generated process, rather than writing custom code.

## Define Triggers Using the UI

1.  Under **Operations Explorer**, select the operation.

2.  Under **Operation Components**, select **Triggers**.

3.  Enter the required information for your trigger.

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p><strong>Name</strong></p></td><td><p>The variable name for the trigger, used as its identifier in your code.</p></td></tr><tr><td><p><strong>Display Name</strong></p></td><td><p>The user-friendly name shown in the UI.</p></td></tr><tr><td><p><strong>Operation Output Type</strong></p></td><td><p>The data type returned by the operation, typically an array or collection.</p></td></tr><tr><td><p><strong>Operation Result Item Type</strong></p></td><td><p>The type of each item in the operation output.</p></td></tr><tr><td><p><strong>Trigger Result Item Type</strong></p></td><td><p>The type of each item the trigger emits. This is usually the same as the Operation Result Item Type unless you transform the data.</p></td></tr><tr><td><p><strong>Order</strong></p></td><td><p>The order in which items are processed or emitted, such as Ascending (oldest to newest) or Descending (newest to oldest).</p></td></tr><tr><td><p><strong>Input Records</strong></p></td><td><p>The path to the array of items in the operation response.</p></td></tr><tr><td><p><strong>Item</strong></p></td><td><p>The path to a single item within the array. Leave blank if items are at the root of the array.</p></td></tr><tr><td><p><strong>Identity Field</strong></p></td><td><p>The unique identifier for each item.</p></td></tr><tr><td><p><strong>Watermark Field</strong></p></td><td><p>The field used to track the last processed item, often for incremental sync.</p></td></tr><tr><td><p><strong>Watermark Type</strong></p></td><td><p>The data type of the watermark field.</p></td></tr><tr><td><p><strong>Initial Watermark</strong></p></td><td><p>The starting value for the watermark, such as the earliest date to start processing from. Leave blank to process all records.</p></td></tr></tbody></table>

    For example, let’s say you want to create a trigger for when a new contact is created. Suppose
    your operation response looks like this:

    ```none
    type OperationResponse = {
      value: {
        contacts: Array<Contact>
        // ... other fields
      }
      // ... other fields
    }
    ```

    And the `Contact` type is defined as:

    ```none
    type Contact = {
      id: String
      name: String
      lastModifiedDate: DateTime
      // ... other fields
    }
    ```

    The required information for your trigger looks like this:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p><strong>Name</strong></p></td><td><p><code>newContactCreatedTrigger</code></p></td></tr><tr><td><p><strong>Display Name</strong></p></td><td><p><code>New Contact Created Trigger</code></p></td></tr><tr><td><p><strong>Operation Output Type</strong></p></td><td><p><code>Contact[]</code> (if your operation returns a list of contacts)</p></td></tr><tr><td><p><strong>Operation Result Item Type</strong></p></td><td><p><code>Contact</code></p></td></tr><tr><td><p><strong>Trigger Result Item Type</strong></p></td><td><p><code>Contact</code></p></td></tr><tr><td><p><strong>Order</strong></p></td><td><p>Ascending (oldest to newest) or Descending (newest to oldest)</p></td></tr><tr><td><p><strong>Input Records</strong></p></td><td><p><code>value.contacts</code></p></td></tr><tr><td><p><strong>Item</strong></p></td><td><p>(Leave blank if items are at the root of the array)</p></td></tr><tr><td><p><strong>Identity Field</strong></p></td><td><p><code>id</code></p></td></tr><tr><td><p><strong>Watermark Field</strong></p></td><td><p><code>lastModifiedDate</code></p></td></tr><tr><td><p><strong>Watermark Type</strong></p></td><td><p><code>DateTime</code></p></td></tr><tr><td><p><strong>Initial Watermark</strong></p></td><td><p><code>2023-01-01T00:00:00Z</code></p></td></tr></tbody></table>

4.  Optionally, you can add parameters to your trigger to further customize its behavior. Enter the
    required information for your parameters.

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p><strong>Trigger Input Param Type</strong></p></td><td><p>The parameter type of the trigger input.</p></td></tr><tr><td><p><strong>Parameter Name</strong></p></td><td><p>The parameter name.</p></td></tr><tr><td><p><strong>Type</strong></p></td><td><p>The parameter type.</p></td></tr></tbody></table>

    These parameters are used to generate the trigger’s `inputMapper`. Depending on your parameter
    choices, the generated `inputMapper` code will look like one of these:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Parameter Scenario</th><th>Example <code>inputMapper</code> Code</th></tr></thead><tbody><tr><td><p><strong>No parameters defined</strong></p></td><td><div><div><div><pre><code>inputMapper: (
        param: {},
        watermark: ${watermarkType}
      ) -&gt; {
        query: {},
        headers: {},
        cookie: {}
      },</code></pre></div></div></div></td></tr><tr><td><p><strong>Simple parameters defined</strong></p></td><td><div><div><div><pre><code>inputMapper: (
        param: { param1: String, param2: Number },
        watermark: ${watermarkType}
      ) -&gt; {
        query: {},
        headers: {},
        cookie: {}
      },</code></pre></div></div></div></td></tr><tr><td><p><strong>Only a complex type parameter defined</strong></p></td><td><div><div><div><pre><code>inputMapper: (ti: T_Complex, w) -&gt; ti</code></pre></div></div></div></td></tr><tr><td><p><strong>Complex type with additional parameters</strong></p></td><td><div><div><div><pre><code>inputMapper: (
        param: { param1: String, param2: Number } &amp;&amp; T_Complex,
        watermark: ${watermarkType}
      ) -&gt; {
        query: {},
        headers: {},
        cookie: {}
      },</code></pre></div></div></div></td></tr></tbody></table>

5.  Click **Create Trigger**.

    This generates a new `.dwl` file in the `triggers` directory, containing both the trigger and
    its corresponding trigger strategy. The generated code follows this template:

    ```none
    var <%= trigger.triggerStrategy.name %>: TriggerStrategy<<%- trigger.triggerStrategy.operationOutputType %>, <%- trigger.triggerStrategy.triggerResultItemType %>, <%- trigger.triggerStrategy.operationResultItemType %>, <%- trigger.watermarkType %>> = {
      items: (result) -> result<%- trigger.triggerStrategy.result === '' ? '' : `.${trigger.triggerStrategy.result}` %>!,
      item: (item) -> item<%- trigger.triggerStrategy.item === '' ? '' : `.${trigger.triggerStrategy.item}` %>,
      watermark: (result, item) -> item.<%- trigger.triggerStrategy.watermarkField %>! as <%- trigger.watermarkType %>,
      identity: (item) -> item.<%- trigger.triggerStrategy.identityField %>! as String,
      watermarkCompareTo: DefaultWatermarkComparison
    }

    var <%= trigger.name %>Trigger  = {
      name: "<%= trigger.name %>",
      displayName: "<%= trigger.displayName %>",
      metadata: {
        order: "<%= trigger.order %>",
        paginated: <%= trigger.isPaginated %>,
      },
      strategy: <%= trigger.triggerStrategy.name %>,
      operation: <%= srcModuleName %>,
      inputMapper: <%- trigger.inputMapper %>,
      initialWatermark: (triggerInput, connection) -> <%- trigger.initialWatermark || 'Null' %>
    }
    ```

6.  Import your trigger and add it to the `triggers` section of your `Connector.dwl` file:

    ```none
    @FlowConnectorElement()
    var connector = {
    ...,
    triggers: {
      myTrigger: myTrigger,
    },
    ...
    }
    ```

## Define Triggers Using LinkWeave

To add a trigger to the connector, you must add the trigger to the connector definition:

```none
@FlowConnectorElement()
var connector = {
    name: "ReferenceConnector",
    displayName: "Reference Connector",
    connections: connections,
    testConnection: testConnection,
    operations: {
        findCategoriesOperation: findCategoriesOperation
    },
    triggers: {
        onNewCategoryTrigger: triggers.onNewCategoryTrigger
    }
}
```

Defining a trigger in LinkWeave is similar to defining an operation. Here’s an example of a trigger
definition:

```none
// Declare the trigger
var onNewCategoryTrigger = {
    name: "onNewCategoryTrigger",
    displayName: "On new category Trigger",
    metadata: {
        order: "ASC",         // "ASC", "DESC", or "NO_ORDER"
        paginated: false      // Set to true if the response is paginated
    },
    strategy: onNewCategoryTriggerStrategy,
    operation: findCategoriesOperation,
    inputMapper: (ti: PaginatedOperationTypes.findPets.request, w) -> ti,
    initialWatermark: (triggerInput, connection) -> now()
}
```

There are four attributes specific to triggers that are different from operations.

- [strategy](#strategy)

- [operation](#operation)

- [inputMapper](#inputmapper)

- [initialWatermark](#initialwatermark)

### strategy

The trigger extraction strategy determines how to obtain each event from the operation’s response.
This includes how to extract the list of events, determine if each event must be transformed before
it’s returned, retrieve the watermark from each event, determine each event’s unique identity, and
compare watermarks between events (in almost all cases, this is a simple comparison such as A > B).
For example, here’s the definition of the trigger extraction strategy for this trigger:

```none
// Declare the trigger strategy.
var onNewCategoryTriggerStrategy: TriggerStrategy<HttpResponse<findCategorySuccessResponse>, Types.Category, Types.Category, Number> = {
    // Extract the list of items from the SaaS response.
    items: (result) -> result.body!,
    // Transform each item if needed.
    item: (item) -> item,
    // Extract the watermark from each item.
    watermark: (result, item) -> item.id,
    // Extract the identity from each item.
    identity: (item) -> item.id as String,
    // Compare two watermarks (default: A > B).
    watermarkCompareTo: DefaultWatermarkComparison
}
```

The `TriggerStrategy` type parameters are:

- `OperationOutputType`: The operation output type that the trigger is based on. In this example,
  it’s `HttpResponse<findCategorySuccessResponse>`.

- `TriggerResultItemType`: The final item or event type to show as a result of the trigger. In this
  example, it’s `Types.Category`. It’s the same as `OperationResultItemType`, which means no
  transformation.

- `OperationResultItemType`: The item or event type that the operation execution returns. In this
  example, it’s `Types.Category`.

- `Watermark`: The item or event watermark type. In this example, it’s `Number`.

You can also define a non-typed strategy as long as the trigger is typed:

```none
var onNewCategoryTriggerStrategy = {
    items: (result) -> result.body!,
    item: (item) -> item,
    watermark: (result, item) -> item.id,
    identity: (item) -> item.id as String,
    watermarkCompareTo: DefaultWatermarkComparison
}
```

### operation

A trigger always executes an operation. The operation it’s based on becomes an attribute of the
trigger. For example, here’s the definition of the operation for this trigger:

```none
type findCategoryRequest: HttpRequestType<{|
    query: { company: Number },
    headers: Object,
    cookie: Object
|}>

type findCategorySuccessResponse: Array<Types.Category>
type findCategoryErrorResponse: Types.Error

var findCategoriesOperation = {
    name: "findCategories",
    displayName: "findCategories",
    executor: (parameter: findCategoryRequest, connection: HttpConnection): Result<HttpResponse<findCategorySuccessResponse>, HttpResponse<findCategoryErrorResponse>> -> do {
        var uri = parameter.uri
        var query = parameter.query default {}
        var headers = parameter.headers default {}
        var cookie = parameter.cookie default {}
        var response = connection({
            method: "GET",
            path: "/categories",
            queryParams: query,
            headers: headers,
            cookie: cookie,
            (body: parameter.body) if (parameter.body?)
        })
        ---
        response.status match {
            case 200 -> success(response as HttpResponse<findCategorySuccessResponse>)
            else -> failure(response as HttpResponse<findCategoryErrorResponse>)
        }
    }
}
```

Triggers can be based on operations that return either paginated or non-paginated responses, as
specified by the API. This affects the trigger’s metadata and strategy.

- For non-paginated operations, the output type is typically
  `HttpResponse<findCategorySuccessResponse>`, and items are accessed via `result.body!` or
  `result.body!.items`.

- For paginated operations, the output type is a `Page` type (such as
  `Page<Types.Category, findCategoryRequest>`), and items are accessed via `result.items`.

From the user’s perspective, a trigger exposes a single event type as its output metadata. However,
the actual result of a poll is more complex, typically returning a `Page` type along with
information for the next poll cycle.

### inputMapper

The `inputMapper` function maps the trigger’s input and the current watermark to the operation’s
input type. For example, here’s the definition of `inputMapper` for this trigger:

```none
inputMapper: (TriggerInputType, Watermark) -> OperationInputType
```

When a trigger is executed, it receives input parameters that must ultimately be mapped to the
request parameters expected by the underlying operation. The `inputMapper` function is responsible
for transforming the trigger’s input (which might differ in shape or content from the operation’s
input) into the format required by the operation. This function is a required attribute of the
trigger.

Suppose [`findCategoriesOperation`](#operation) defines this input:

```none
  type findCategoryRequest: HttpRequestType<{|
      query: {
        company: Number,
      },
      headers: Object,
      cookie: Object
  |}>
```

Suppose the `company` value is fixed for the connector, and the trigger itself doesn’t require any
input parameters. In this case, the `inputMapper` function can ignore its input and simply return
the required structure for the operation:

```none
  type NewEmptyInputType = {| |}

  // declare the trigger
  var onNewCategoryTrigger = {
      ...
      operation: findCategoriesOperation,
      inputMapper: (myNewTriggerInput: NewEmptyInputType, watermark: Number) ->
          { query: { company: "mulesoft" }, headers: {}, cookie: {} }
  }
```

The `inputMapper` is a lambda that takes the trigger’s input type and the watermark, and returns the
operation’s input type (`findCategoryRequest`). In this case, the trigger input isn’t used, but in
other scenarios, it might be necessary. Common use cases for `inputMapper` include:

- **Reshaping the input**

  Sometimes, the operation’s input type (such as `HttpRequestType`) isn’t ideal for the trigger’s
  user experience. You can define a new, simpler input type for the trigger and use `inputMapper` to
  convert it to the operation’s expected input:

  ```none
    type NewInputType = { company: Number }

    // declare the trigger
    var onNewCategoryTrigger = {
        ...
        operation: findCategoriesOperation,
        inputMapper: (myNewTriggerInput: NewInputType, watermark: Number) ->
            { query: { company: myNewTriggerInput.company }, headers: {}, cookie: {} }
    }
  ```

  The trigger input is now an object that contains the `company` parameter only and at root level.

- **Using the last stored watermark**

  Another common scenario is a date-based trigger, in which the operation’s input includes a date
  field (such as `since` or `from`) to fetch results from a certain point in time. This value is
  often used as the watermark. For example, you might want the trigger to hide the `since` parameter
  from the user and instead use the last stored watermark value:

  ```none
    type findCategoryRequest: HttpRequestType<{|
        query: {
          company: Number,
          since: LWDate
        },
        headers: Object,
        cookie: Object
    |}>
  ```

  The new input type and the `inputMapper` function is:

  ```none
    type NewInputType = { company: Number }

    // declare the trigger
    var onNewCategoryTrigger = {
        ...
        operation: findCategoriesOperation,
        inputMapper: (myNewTriggerInput: NewInputType, watermark: String) ->
            {
                query: {
                    company: myNewTriggerInput.company,
                    since: watermark
                },
                headers: {}, cookie: {}
            }
    }
  ```

- **Optional starting point**

  A related pattern is to allow the user to optionally specify a starting point, falling back to the
  watermark if not provided:

  ```none
    type CustomGetUsersRequestPaginated = {| startDate? : Number |}

    // Example inputMapper
    (ti: CustomGetUsersRequestPaginated, w: Number) -> { since: ti.startDate default w }
  ```

  In this case, the trigger input includes an optional `startDate`. If the user doesn’t provide a
  value, the mapper uses the watermark. This approach is often combined with annotations to hide the
  parameter in certain platforms, so the watermark is used automatically. In platforms that don’t
  recognize the annotation, the parameter remains visible and can be set by the user.

### initialWatermark

The `initialWatermark` function determines the starting watermark for the polling cycle. This can be
a fixed value, a dynamic value (such as `now()`), or calculated by executing an operation. For
example, here’s the definition of `initialWatermark` for this trigger:

```none
initialWatermark: (TriggerInputType, ConnectionType) -> Watermark
```

<!-- document id=66855600b12d324fee90d0e07be49f355250f53768b3f5917c76f1918336ea6a url=/mulesoft/current/en-us/connector-builder/troubleshooting.md -->

---
product: Connector Builder
version: master
---

# Troubleshooting Connector Builder

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Learn how to troubleshoot issues with Connector Builder.

## Access Error Logs

To access error logs in Connector Builder:

1.  Click **View** > **Output**.

2.  In the dropdown menu, select **Connector Builder**.

To modify the output log level, in the Connector Builder extension, go to **Settings** and find
**Linkweave › Logging: Level**.

## Connector Generation Using an API Spec

Connector Builder supports only OAS 3.0 API specifications. If you encounter issues, you can use
[Anypoint Code Builder - API Extension](https://marketplace.visualstudio.com/items?itemName=salesforce.mule-dx-api-component)
to validate the API Spec.

## Connector Generation Using AI Assistance

Even when given well-crafted prompts, AI might sometimes hallucinate. This can be influenced by
factors such as the specific model in use and the quality of the API documentation it processes.

When creating a project using AI assistance, it’s important to recognize that the initial output is
a starting point rather than a finalized solution. You should thoroughly review and validate the
AI-generated results, as AI might occasionally misinterpret, omit, or misunderstand aspects of a
service’s documentation.

If you encounter issues with a connector generated using AI assistance, ensure you review and
compare the AI-generated API specification against the official service documentation. This review
should focus on, but not be limited to, these areas:

- **Endpoints**: Ensure all required API endpoints are present and accurately defined.

- **HTTP Methods**: Verify that each endpoint uses the correct HTTP methods (`GET`, `POST`, `PUT`,
  `DELETE`, and so on.).

- **Parameters**: Confirm that all necessary parameters, including their data types, formats,
  locations (path, query, header, body), and validation rules, are correctly specified.

- **Request and Response Schemas**: Check that the structures and data types of both request and
  response bodies are correct, including complex data types like nested objects, arrays, and enums.

- **Authentication and Authorization**: Make sure the specification accurately describes
  authentication and authorization mechanisms (such as API keys or OAuth 2.0) required by the
  service.

- **Error Handling**: Ensure that typical error responses and their corresponding status codes are
  properly documented.

## Unable to Locate Operation for TestConnection Element

This error typically occurs during the initial generation of a connector. To ensure a successful
connection test, the system requires a simple `GET` operation without any required parameters. This
operation automatically gets included by the code generator. If no such operation is found in the
API specification, you will encounter the
`Could not find an operation for the TestConnection element` error.

If you encounter this error, you have two options:

- **Skip and continue generating the connector**: This allows you to proceed with connector
  generation, but you will need to manually define a custom operation for testing the connection.

- **Cancel generation and modify the API specification**: You can halt the generation process,
  update your API specification to include a `GET` operation that meets the criteria (no required
  parameters), and then restart the connector generation.

## Deletion of Custom Operations and Types when Regenerating a Connector

To safeguard any custom operations or types you’ve added to prevent their accidental deletion,
organize your custom elements within dedicated folders:

- **Custom Operations**: Create a customizations folder inside the operations folder and place all
  your custom operation definitions within it.

- **Custom Types**: Similarly, for custom types, create a customizations folder within the types
  folder and add your custom type definitions there.

By following this structure, the regeneration process recognizes these dedicated folders and
preserves your custom work.

## Operations Missing from a Connector

Some operations might be missing from a connector if they were removed as part of our mitigation
strategies to ensure out-of-the-box compatibility with the target platform.

Details of these removals can be found in the mitigation report that appears upon connector
generation or regeneration.

If you want to turn off these mitigations, go to **Settings** and disable **Linkweave › Features ›
Mitigations**.

## Parameters Defined as Union Type

In Anypoint Studio, the parameter doesn’t appear in the operation’s UI. In Anypoint Code Builder,
the parameter is shown but produces an error when you try to view its details. An example of an
unsupported type is `type unionParameter = Type1 | Type2`. This is because Anypoint Connectors don’t
allow for any of the parameters to be defined as a union type.

Anypoint Connector operations are defined as transformations of the canonical connectivity model
(CCM) operations. For example:

```none
type anypoint_O_projects_api_v3_projects_updates_json_get_request = {
  updatedAfter?: O_projects_api_v3_projects_updates_json_get_Type.request.query.updatedAfter,
  // ... other fields
}

var anypoint_O_projects_api_v3_projects_updates_json_get_mapping = [
  "updatedAfter" mapsTo "query.updatedAfter",
  // ... other mappings
  {} defaultOf "query",
  {} alwaysMapsTo "headers",
  {} alwaysMapsTo "cookie"
]

@OperationElement()
var anypoint_O_projects_api_v3_projects_updates_json_get = O_projects_api_v3_projects_updates_json_get withTransformer {
  in: fromMapping<anypoint_O_projects_api_v3_projects_updates_json_get_request, O_projects_api_v3_projects_updates_json_get_Type.request>(anypoint_O_projects_api_v3_projects_updates_json_get_mapping),
  out: extractRequestBody
}
```

This code translates into an Anypoint Connector operation with all fields as parameters of the CCM
operation. None of the field values can be of union type. In the example,
`O_projects_api_v3_projects_updates_json_get_Type.request.query.updatedAfter` can’t be a union type.
To determine this manually, you must navigate to the definition of this type in the connectivity
model to see if it is a union type.

You can either:

- Omit the operation.

- Remove the parameter from the operation.

- Change the parameter’s type to Object or another appropriate type.

## LLM Asks for Input

If the LLM asks for input, provide the input or restart the conversation in a new chat window.

## LLM Doesn’t Create Files

If the LLM doesn’t create the files, ensure that you approve the changes proposed by the LLM, both
for `discovery.json` and the API specification.

## LLM Indicates Completion, but Files Are Missing

Occasionally, the LLM might incorrectly state that it has created the API specification when it has
not. In such cases, you can manually copy the API specification content provided by the LLM, save it
as a YAML file in the project root, and the extension should automatically detect the file and begin
the generation process.

## See Also

- [Known Issues](https://help.salesforce.com/s/issues)

<!-- document id=f61e9d38d6bc5479468d839336c19318b83902219fed1946cf836c13f444275e url=/mulesoft/current/en-us/connector-builder/value-providers.md -->

---
product: Connector Builder
version: master
---

# Value Providers

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Learn how to define value providers for your connector. Value providers are functions that show a
list of valid options for a given field. This enhances the user experience by presenting selectable
choices instead of requiring users to remember or manually enter valid values. For example, you can
define a value provider to show a list of ISO country codes.

Connector Builder supports:

- Static value providers (String enums, Numeric enums)

- Dynamic value providers

- Value provider pagination

## Define Value Providers Using LinkWeave

Attaching value providers to types allows the platform to automatically retrieve and display
possible values for fields that use those types.

For example, suppose you have a connector with an operation that retrieves the population for a
given country:

```none
var getPopulation : Operation<{country: CountryIsoCode}> = {
    // ...
}
```

Here, the `country` parameter expects an ISO country code (for example, `AR`, `US`, or `BR`).
Instead of asking users to remember these codes, you can define a value provider to supply the list
of valid countries.

1.  Define an operation to fetch the list of countries:

    ```none
    var getCountries = // ...
    ```

2.  Create the value provider using `defineValueProvider`. This function takes two arguments: the
    executor for fetching the data, and a transformation function to map the response to the
    required format:

    ```none
    var countriesValueProvider = defineValueProvider(
        getCountries.executor,
        (response: HttpResponse<{items: Array<Country>}>) ->
            response.body.items map ((item, index) -> {
                value: item.isoCode,
                displayValue: { label: item.name }
            })
    )
    ```

    The transformation function must return an array of objects with this structure:

    ```none
    {
        value: VALUE, // The actual value to be used as input
        displayValue: {
            label: LABEL // The label shown to the user for this value
        }
    }
    ```

3.  Add the value provider to your connector declaration:

    ```none
    @FlowConnectorElement()
    var connector = {
        name: "WorldInfo",
        // ...
        operations: {
            getPopulation: getPopulation,
            getCountries: getCountries
        },
        valueProviders: {
            countriesValueProvider: countriesValueProvider
        }
    }
    ```

    Now, the value provider can be referenced by any operation that requires a country input.

4.  Annotate the parameter in your operation to use the value provider:

    ```none
    var getPopulation : Operation<{country: @ValuesFrom(value = { name: countriesValueProvider }) CountryIsoCode}> = {
        // ...
    }
    ```

    With this setup, users see a dropdown of country names when selecting a country, and the
    corresponding ISO code is used as the input value.