---
schema_version: "1"
id: b97ef670e2793c1b77f9491deacbe668417507973bea1a2bf9d2dfc04531879a
title: Integration Use Cases
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/gateway/latest/gateway-architecture-uc-overview.md
canonical_url: https://docs.mulesoft.com/gateway/latest/gateway-architecture-uc-overview
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 2abbb06896082e2ca9b501a5b52c0f2d0ea4ad0b0c96cb459e97d839f1d9083c
description: MuleSoft Documentation Site
release: "1.14"
latest: true
---
---
product: Omni Gateway
version: 1.14
is-latest-version: true
---

# Integration Use Cases

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

The following integration use cases are determined by the ownership of the API provider and API
consumer. Each use case shows physical patterns that demonstrate the necessary services in the
system.

For the following use case diagrams, Omni Gateway is running in Connected Mode. However, you can
also run Omni Gateway in Local Mode or use a combination of Connected Mode and Local Mode for
separate runtimes in the same or in different environments.

The use case diagrams use Kubernetes terminology, but you can extend the architecture to other
technology stacks that have the appropriate network controls applied.

Omni Gateway supports four use cases:

- [Use Case 1: Organization-Owned API Exposed to an Organization-Owned API Consumer](https://docs.mulesoft.com/gateway/latest/gateway-architecture-uc1)

- [Use Case 2: Organization-Owned API Exposed to a Non-Organization-Owned API Consumer](https://docs.mulesoft.com/gateway/latest/gateway-architecture-uc2)

- [Use Case 3: Non-Organization-Owned API Exposed to an Organization-Owned API Consumer](https://docs.mulesoft.com/gateway/latest/gateway-architecture-uc3)

- [Use Case 4: Non-Organization-Owned API Exposed to a Non-Organization-Owned API Consumer](https://docs.mulesoft.com/gateway/latest/gateway-architecture-uc4)

![The four use cases are linked to products that they can support.](/mulesoft/current/en-us/gateway/latest/_images/ad-intergration-use-cases.png)

Each use case supports different integration patterns that vary depending on the location of APIs
relative to the network in which Omni Gateway is located. You can use different use case patterns,
depending on the different API owners and networks in your system.

In each use case, there are three different classifications of networks. The classifications
describe the relation of each network to your organization and the network that Omni Gateway is in:

- Organization internal

  Networks owned by your organization and in the same network as Omni Gateway

- Organization external

  Trusted networks external to your organization but in a different network than Omni Gateway, for
  example, your organization’s Splunk instance

- Non-Organization external

  External networks untrusted by your company and in a different network as Omni Gateway. An API
  provider’s or API consumers network status affects the necessary security protocols (mTLS) you
  take when communicating between networks

If an API provider or API consumer is organization-owned, it belongs to either the organization’s
internal network or its external networks.

The following tables:

- Relate the previously mentioned use cases to use case patterns

- Show the networks involved in the pattern

- Indicate whether Omni Gateway acts as an ingress, egress, or both

## Use Case 1: Organization-Owned API Exposed to an Organization-Owned API Consumer

<table><colgroup><col> <col> <col> <col></colgroup><thead><tr><th>Pattern</th><th>Provider Network</th><th>Consumer Network</th><th>Role of Omni Gateway</th></tr></thead><tbody><tr><td><div><div><p><a href="https://docs.mulesoft.com/gateway/latest/gateway-architecture-uc1#pattern-1a">Pattern 1A: Organization internal API exposed to an organization internal consumer that uses the same VPC or network as the API</a></p></div></div></td><td><div><div><p>Organization internal</p></div></div></td><td><div><div><p>Organization internal</p></div></div></td><td><div><div><p>Ingress</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/gateway/latest/gateway-architecture-uc1#pattern-1b">Pattern 1B: Organization internal API exposed to an organization internal consumer that uses a different VPC or network from the API</a></p></div></div></td><td><div><div><p>Organization internal</p></div></div></td><td><div><div><p>Organization internal</p></div></div></td><td><div><div><p>Ingress</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/gateway/latest/gateway-architecture-uc1#pattern-2">Pattern 2: Organization internal API exposed to an organization external consumer</a></p></div></div></td><td><div><div><p>Organization internal</p></div></div></td><td><div><div><p>Organization external</p></div></div></td><td><div><div><p>Ingress</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/gateway/latest/gateway-architecture-uc1#pattern-3">Pattern 3: Organization external API exposed to an organization internal consumer</a></p></div></div></td><td><div><div><p>Organization external</p></div></div></td><td><div><div><p>Organization internal</p></div></div></td><td><div><div><p>Egress</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/gateway/latest/gateway-architecture-uc1#pattern-4">Pattern 4: Organization external API exposed to an organization external consumer</a></p></div></div></td><td><div><div><p>Organization external</p></div></div></td><td><div><div><p>Organization external</p></div></div></td><td><div><div><p>Ingress and egress</p></div></div></td></tr></tbody></table>

## Use Case 2: Organization-Owned API Exposed to a Non-Organization-Owned API Consumer

<table><colgroup><col> <col> <col> <col></colgroup><thead><tr><th>Pattern</th><th>Provider Network</th><th>Consumer Network</th><th>Role of Omni Gateway</th></tr></thead><tbody><tr><td><div><div><p><a href="https://docs.mulesoft.com/gateway/latest/gateway-architecture-uc2#pattern-5">Pattern 5: Organization internal API exposed to a non-organization external consumer</a></p></div></div></td><td><div><div><p>Organization internal</p></div></div></td><td><div><div><p>Non-organization external</p></div></div></td><td><div><div><p>Ingress</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/gateway/latest/gateway-architecture-uc2#pattern-6">Pattern 6: Organization external API exposed to a non-organization external consumer</a></p></div></div></td><td><div><div><p>Organization external</p></div></div></td><td><div><div><p>Non-organization external</p></div></div></td><td><div><div><p>Ingress and egress</p></div></div></td></tr></tbody></table>

## Use Case 3: Non-Organization-Owned API Exposed to an Organization-Owned API Consumer

<table><colgroup><col> <col> <col> <col></colgroup><thead><tr><th>Pattern</th><th>Provider Network</th><th>Consumer Network</th><th>Role of Omni Gateway</th></tr></thead><tbody><tr><td><div><div><p><a href="https://docs.mulesoft.com/gateway/latest/gateway-architecture-uc3#pattern-7">Pattern 7: Non-organization external API exposed to an organization internal consumer</a></p></div></div></td><td><div><div><p>Non-organization external</p></div></div></td><td><div><div><p>Organization internal</p></div></div></td><td><div><div><p>Egress</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/gateway/latest/gateway-architecture-uc3#pattern-8">Pattern 8: Non-organization external API exposed to an organization external consumer</a></p></div></div></td><td><div><div><p>Non-organization external</p></div></div></td><td><div><div><p>Organization external</p></div></div></td><td><div><div><p>Ingress and egress</p></div></div></td></tr></tbody></table>

## Use Case 4: Non-Organization-Owned API Exposed to an External Non-Organization-Owned API Consumer

<table><colgroup><col> <col> <col> <col></colgroup><thead><tr><th>Pattern</th><th>Provider Network</th><th>Consumer Network</th><th>Role of Omni Gateway</th></tr></thead><tbody><tr><td><div><div><p><a href="https://docs.mulesoft.com/gateway/latest/gateway-architecture-uc4#pattern-9">Pattern 9: Non-organization external API exposed to a non-organization external consumer</a></p></div></div></td><td><div><div><p>Non-organization external</p></div></div></td><td><div><div><p>Non-organization external</p></div></div></td><td><div><div><p>Ingress and egress</p></div></div></td></tr></tbody></table>

## mTLS considerations for integration flows

Omni Gateway supports Mutual Transport Layer Security (mTLS) for all Omni Gateway-initiated and Omni
Gateway-terminated connections. Mulesoft recommends using mTLS on all communication flows.

For inbound connections that cross a network security boundary, use a network application firewall
as close to the boundary as possible. For inbound connections, configure the external mTLS
connection to terminate at the firewall and configure a new mTLS context between the firewall and
Omni Gateway.

### Certificate authorities

Different certificate authorities (CA) participate in the mTLS connection, depending on the type of
integration. In the use case diagrams, color codes and labels represent the different mTLS contexts.
Each mTLS context contains a truststore that contains CAs for validating far-side certificates and a
keystore that contains a certificate issued by this same CA. The following table describes the three
possible mTLS contexts:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>mTLS context symbol</th><th>Certificate authority</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><span><img src="https://docs.mulesoft.com/gateway/latest/_images/ad-internal-org-mtls.png" alt="Organization internal mTLS symbol"></span></p></div></div></td><td><div><div><p>Organization internal mTLS</p></div></div></td><td><div><div><p>For internal network communication, the expectation is that only the customer organization uses these certificates within the internal network.</p></div></div></td></tr><tr><td><div><div><p><span><img src="https://docs.mulesoft.com/gateway/latest/_images/ad-external-org-mtls.png" alt="Organization external mTLS symbol"></span></p></div></div></td><td><div><div><p>Organization external mTLS</p></div></div></td><td><div><div><p>For external communication with trusted parties over the public internet, the organization can issue certificates that external consumers or third parties can use to access the services provided by the organization.</p></div></div></td></tr><tr><td><div><div><p><span><img src="https://docs.mulesoft.com/gateway/latest/_images/ad-external-non-org-mtls.png" alt="Non-organization external mTLS symbol"></span></p></div></div></td><td><div><div><p>Non-organization external mTLS</p></div></div></td><td><div><div><p>For external communication with entities that aren’t trusted, the third party organization controls the CA. The third party CA issues certificates for the organization to use when communicating with third-party services.</p></div></div></td></tr></tbody></table>

## See Also

- [Omni Gateway Deployment Models](https://docs.mulesoft.com/gateway/latest/gateway-architecture-basic-deployments)

- [Redis Shared Storage Models](https://docs.mulesoft.com/gateway/latest/gateway-architecture-shared-storage)