---
schema_version: "1"
id: c2f0867d30ffb96ef3f9661f3b1d8eb625db77040a82c3d1e5dd2aab61ba2177
title: Build SOAP API Proxies
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/api-manager/latest/building-soap-proxy.md
canonical_url: https://docs.mulesoft.com/api-manager/latest/building-soap-proxy
source_site: docs.mulesoft.com
content_type: documentation
content_hash: a407209539e8437723b94832fabf94d70490b9b959ea31f16570f036cdd9a997
description: MuleSoft Documentation Site
release: 2.x
latest: true
---
---
product: API Manager
version: 2.x
is-latest-version: true
---

# Build SOAP API Proxies

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

API Manager 2.x enables you to use SOAP API proxies for your SOAP-based web services. The SOAP proxy
requires a WSDL definition that describes the backend service. The WSDL defines how the API proxy
must perform validations on incoming requests and correctly routes outbound requests for the
corresponding API endpoint.

## SOAP Proxy Schema Validation

Regardless of whether validation is enabled for an API, the SOAP request validator always verifies
the following:

- The incoming request has a valid SOAP action.

- The payload is a valid SOAP envelope.

If validation is enabled for an API, the SOAP request validator also verifies that the content of
the `body` tag matches the one defined in the WSDL. The SOAP action in the inbound request is
matched against the same-named operation in the WSDL. The proxy then validates that the namespace
URI of the element and the name associated with the operation match the same details in the incoming
request.

If the validation fails, an error message informing the expected namespace URI and element name is
generated. If the SOAP action in the inbound request is empty, the application then attempts to
match the namespace URI and element name of the incoming request element to all the operations
defined in the WSDL.

The first operation that matches the incoming request determines whether the validation is
successful. If the match fails, an error message is generated with the suggested tag names for the
element in the request.

## Retrieving the WSDL from the Proxy Application

The SOAP proxy allows the backend web service to post requests (POST) and to retrieve (GET) the
service WSDL. The GET request is performed by an HTTP GET method with either `wsdl` or `WSDL` as the
query parameter:

- `[http://my-proxy-url:myProxyPort?wsdl](http://my-proxy-url:myProxyPort?wsdl)`

- `[http://my-proxy-url:myProxyPort?WSDL](http://my-proxy-url:myProxyPort?WSDL)`

## Configuring a WSDL from Remote Location Using Basic Authentication Credentials

You can access a protected WSDL that is hosted on a remote location by configuring the
`basic.auth.user` and `basic.auth.password` application properties in the `basicauth.properties`
configuration file. The properties are then passed to the validator module:

```xml
<soap-request-validator:config name="validator-config" wsdlLocation="http://myremoteurl:9092/service?wsdl" serviceName="myServiceName"
                                   servicePort="myServicePort" schemaValidationEnabled="true"
                                   basicAuthUser="${basic.auth.user}" basicAuthPassword="${basic.auth.password}"/>
```

If you do not provide authentication values for the properties, the WSDL is retrieved
unauthenticated.

## Retrieving a WSDL Using TLS

With SOAP proxy v2.1.0, you can retrieve a WSDL from a remote location using the TLS context
configuration by default. The TLS context used for this operation is the same as the outbound
configuration of the proxy.

## Configure Your SOAP Proxy

Configure your SOAP proxy by completing the following steps:

1.  Navigate to **Anypoint Platform** > **API Manager**.

2.  In **API Administration**, click **Add API** and select **Add new API**.

3.  Select **Mule Gateway** as your runtime.

4.  Select **Deploy a proxy application** for **Proxy type**.

5.  If you selected to deploy a proxy application, select the **Target type** from the following
    options:

    - **CloudHub 2.0**: Select this option if you want to use the Mule runtime hosted by MuleSoft in
      a container-based cloud infrastructure. The CloudHub 2.0 proxy includes a CPU with 0.1 vCores
      by default.

      1.  Select a space.

          To learn more about spaces, see [Shared Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-shared-space-about)
          and [Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-private-space-about).

      2.  In **Runtime version**:

          1.  Select the **Runtime Channel**.

          2.  Select the **Version** for Mule runtime.

          3.  Select the **Java version**.

      3.  Enter a **Proxy app name**.

    - **CloudHub**: Select this option if you want to use the Mule runtime hosted on the cloud by
      MuleSoft. The CloudHub proxy includes a CPU with 0.1 vCores and a memory of 500 MB, by
      default.

      1.  In **Runtime version**:

          1.  Select the **Runtime Channel**.

          2.  Select the **Version** for Mule runtime.

          3.  Select the **Java version**.

      2.  Enter a **Proxy app name**.

    - **Hybrid:** Select this option if you want to use a Mule runtime instance running on an
      on-premises server that is registered in Runtime Manager.

      See [Register a server in Runtime Manager](https://docs.mulesoft.com/runtime-manager/servers-create) for more
      information.

      1.  Select a target from the list or click **Add server**.

      2.  Enter a **Proxy app name**.

    - **Self-managed Server:** Select this option if you want to create a JAR file to deploy an API
      proxy to a Mule runtime instance running on an on-premises server that is not registered in
      Runtime Manager. For more information, see
      [On-Premises Mule Runtime Deployment Model](https://docs.mulesoft.com/on-premises/latest/mule-deployment-model).

Deploying an API proxy to a self-managed server in API Manager doesn’t deploy the proxy to your
on-premises server. After you deploy the proxy in API Manager, deploy the proxy to your on-premises
server: . [Download your new API proxy JAR file](https://docs.mulesoft.com/api-manager/latest/download-proxy-task). .
[Deploy the JAR file to your on-premises server](https://docs.mulesoft.com/mule-runtime/latest/deploy-on-premises).

- **Runtime Fabric:** Select Runtime Fabric if you want to deploy API Proxies to a Mule runtime
  engine that is managed on Runtime Fabric. See
  [Deploying API Proxies to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/proxy-deploy-runtime-fabric)
  for more information.

  1.  Select a target from the list.

  2.  In **Runtime version**:

      1.  Select the **Runtime Channel**.

      2.  Select the **Version** for Mule runtime.

      3.  Select the **Java version**.

  3.  Enter a **Proxy app name**.

      1.  Select an API from the following options:

- Click **Select API from Exchange** if you have an API shared with you through Exchange that you
  want to manage.

  1.  Click the API from the list under **Select API**. You can search for a specific API if needed.

  2.  Update the **Asset type**, **API version**, and **Asset version** if you are not using the
      latest version.

      For more information about versions in Exchange, see
      [Asset Versions](https://docs.mulesoft.com/exchange/asset-versions).

  3.  If you chose a **RAML/OAS** asset type, view the **Conformance Status** of the API to ensure
      the API is conformant. If the **Conformance Status** is nonconformant, after deployment, view
      the **Governance Report** to find and fix the conformance issues. For more information about
      the **Governance Report**, see [Governing API Instances](https://docs.mulesoft.com/api-manager/latest/govern-api-instances).

- Click **Create new API**:

  1.  Enter a **Name** for the new API asset.

  2.  Select **SOAP API** as the **Asset type**.

  3.  Select either **Upload a WSDL** or **Use an external link** as the method.

  4.  Update the **Asset type**, **API version**, and **Asset version** if needed.

      1.  Click **Next**.

      2.  Configure the downstream configuration settings:

          Expand for configuration settings.

          <table><colgroup><col> <col> <col> <col></colgroup><thead><tr><th>Field Name</th><th>Description</th><th>Required</th><th>Notes</th></tr></thead><tbody><tr><td><p><strong>Protocol</strong></p></td><td><p>Specifies whether to use HTTP or HTTPS for the validations.</p></td><td><p>Yes</p></td><td><p>If you select HTTPS, specify a TLS context for inbound traffic.</p></td></tr><tr><td><p><strong>Inbound TLS</strong></p></td><td><p>Specifies the TLS context to secure inbound traffic.</p></td><td><p>No</p></td><td><p>If you can’t see a context, ensure that you have the correct permissions.</p></td></tr><tr><td><p><strong>Port</strong></p></td><td><p>Specifies the number to use if the displayed port is incorrect.</p></td><td><p>Yes</p></td><td></td></tr><tr><td><p><strong>Base path</strong></p></td><td><p>Specifies the URL prefix for all API paths, relative to the host root. It must start and end with a leading slash <code>/</code>. If the final slash isn’t provided, the system adds it automatically.</p></td><td><p>Yes</p></td><td></td></tr><tr><td><p><strong>Instance label</strong></p></td><td><p>Specifies a label for the API.</p></td><td><p>No</p></td><td><p>If you have multiple managed instances of the same API, add a label to differentiate each instance from the others.</p></td></tr><tr><td><p><strong>Advanced Options</strong></p></td><td></td><td></td><td></td></tr><tr><td><p><strong>Consumer endpoint</strong></p></td><td><p>Specifies a proxy application’s address for consumers to use for sending requests.</p></td><td><p>No</p></td><td></td></tr><tr><td><p><strong>Client provider</strong></p></td><td><p>Specifies a client provider for the API.</p></td><td><p>Yes</p></td><td><p>Anypoint Platform acts as the client provider by default. To configure an external client provider, see <a href="https://docs.mulesoft.com/access-management/managing-api-clients">Client Providers</a>.</p></td></tr><tr><td><p><strong>Request timeout</strong></p></td><td><p>Specifies the duration after which a request times out.</p></td><td><p>No</p></td><td></td></tr><tr><td><p><strong>Proxy Version</strong></p></td><td><p>Specifies the version of the proxy to use for the endpoint.</p></td><td><p>No</p></td><td></td></tr><tr><td><p><strong>Service Name</strong></p></td><td><p>Name of your WSDL service.</p></td><td><p>Yes</p></td><td><p>Only avaliable for WSDL APIs.</p></td></tr><tr><td><p><strong>Service Port</strong></p></td><td><p>Port for your WSDL your service.</p></td><td><p>Yes</p></td><td><p>Only avaliable for WSDL APIs.</p></td></tr><tr><td><p><strong>Service Namespace</strong></p></td><td><p>Namespace of your WSDL service.</p></td><td><p>Yes</p></td><td><p>Only avaliable for WSDL APIs.</p></td></tr><tr><td><p><strong>Enable Console</strong></p></td><td><p>Specifies whether you can expose and test your API specification.</p></td><td><p>No</p></td><td><p>You can specify a different path in <strong>Console Path</strong>, for example, <code>/spec/*</code>. Only available if you have an attached API definition.</p></td></tr><tr><td><p><strong>Validations</strong></p></td><td><p>Specifies whether to validate inbound requests against a provided specification.</p></td><td><p>No</p></td><td><p>Only available if you have an attached API definition.</p></td></tr><tr><td><p><strong>Strict validations (optional)</strong></p></td><td><p>Specifies whether to validate inbound requests against query parameters.</p></td><td><p>No</p></td><td><p>Only available if you have an attached API definition.</p></td></tr><tr><td><p><strong>User Domain</strong></p></td><td><p>Specifies whether to use an API gateway domain.</p></td><td><p>No</p></td><td><p>If you chose <strong>Hybrid</strong> as the proxy deployment target previously in the configuration, ensure that you select this option.</p></td></tr></tbody></table>

      3.  Click **Next**.

      4.  Configure the upstream configuration settings:

          Expand for configuration settings.

          <table><colgroup><col> <col> <col> <col></colgroup><thead><tr><th>Field Name</th><th>Description</th><th>Required</th><th>Notes</th></tr></thead><tbody><tr><td><p><strong>Upstream URL</strong></p></td><td><p>The URL to access for the proxy or the API.</p></td><td><p>Yes</p></td><td><p>For example, you can use the URL of your API asset in Exchange.</p></td></tr><tr><td><p><strong>Outbound TLS</strong></p></td><td><p>Specifies the TLS context to secure outbound traffic.</p></td><td><p>No</p></td><td><p>If you can’t see a context, ensure that you have the correct permissions.</p></td></tr></tbody></table>

      5.  Click **Next**.

      6.  Review your selections and edit them if necessary.

      7.  If you are ready to deploy, click **Save & Deploy**. Otherwise, you can select **Save**,
          to save the instance and deploy it at a later time.

## Troubleshooting SOAP Proxies for Missing Imports on XSD Files

A SOAP proxy can fail during deployment due to an incorrect WSDL definition. For example, the
following error indicates missing imports in one of the XSD files that are a part of the WSDL:

```text
org.xml.sax.SAXParseException; systemId: http://localhost:8080/?wsdl304785538;
lineNumber: 2; columnNumber: 52; src-resolve.4.2: Error resolving component
'myNamespace:myElement’. It was detected that 'myNamespace:myElement' is in namespace
'http://my.namespace.url', but components from this namespace are not referenceable
from schema document 'http://localhost:8080/?wsdl304785538'. If this is the incorrect
namespace, perhaps the prefix of 'myNamespace:myElement' needs to be changed. If this
is the correct namespace, then an appropriate 'import' tag should be added to
'http://localhost:8080/?wsdl304785538'.
```

This issue occurs when the definition of an element that is used in the WSDL file is found in an
external XSD with a namespace other than that of the current WSDL file.

You can resolve this issue by adding the appropriate imports in the WSDL file. For example, for the
exception in the previous example, the WSDL file must contain the following import in the `types`
element:

```text
<types>
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://my.namespace.url" schemaLocation="myXSDFile.xsd"/>
</schema>
</types>
```

## See Also

- [API Proxy](https://docs.mulesoft.com/api-manager/latest/api-proxy-landing-page)

- [Creating an API Instance by Importing from Exchange](https://docs.mulesoft.com/api-manager/latest/create-instance-task-mule)

- [Configure TLS Context for an API](https://docs.mulesoft.com/api-manager/latest/building-https-proxy)
