MuleSoft vs WSO2 API Manager: which fits your API program
Choose MuleSoft if you want Salesforce to run the control plane and runtimes and your API program is already built on Anypoint Exchange and a single contract. Choose WSO2 API Manager if you need the API control plane inside your own network, an Apache-2.0 base you can inspect and extend, or a deployment model you can change without renegotiating. Most readers arrive here because of a renewal, a move from one deployment model to another, a data residency rule, or a decision to self-host the control plane. Each of those triggers can be met by either product, so the choice turns on operating model rather than feature count.
MuleSoft fits best when most integration runtimes already run on CloudHub or CloudHub 2.0, when Runtime Fabric or Anypoint Platform Private Cloud Edition is an accepted path for on-premises work, and when the buyer values one vendor for the gateway, Exchange, monitoring and support. WSO2 API Manager fits best when the control plane must run in your environment, when the team wants the Publisher, Developer Portal, gateway and traffic manager under an open license, or when you want a hybrid model with a WSO2-hosted control plane and on-premises gateways. WSO2 also offers a fully managed SaaS option with a 99.95% SLA, so ask for that figure in writing before relying on it. Confirm which REST, GraphQL and AsyncAPI assets your teams publish today, because WSO2 API Manager supports all three and your existing specifications must import cleanly.
The decision turns on three questions. First, how many integration runtimes sit outside MuleSoft, since a large estate of Mule applications on customer-managed servers raises the cost of moving the control plane but not the cost of keeping it. Second, who will operate the platform: a platform team that can upgrade, patch and back up the control plane, or a vendor that carries that load. Third, whether you need a vendor support subscription. WSO2 sells one that covers expert support, continuous product updates and vulnerability monitoring, and MuleSoft bundles support into its contract. Put those three answers into a written scope before you request quotes from either side.
Which option fits which scenario
This table maps common API management situations to the platform that fits each one better, based on deployment options, licensing and supported API types. Read each row against your own constraints, since several scenarios can point to different answers within one estate.
| Scenario | Better fit | Reason |
|---|---|---|
| API governance on CloudHub 2.0 with no self-hosting requirement | MuleSoft Anypoint Platform | MuleSoft documents CloudHub 2.0 as MuleSoft-managed, so the control plane and runtime operations stay with the vendor. Confirm your contract covers the capabilities you need. |
| APIs that must stay inside your own data centers or cloud accounts | WSO2 API Manager | WSO2 supports on-premises installation from extracted packages and on Kubernetes, and its Apache-2.0 licensing lets you run the product without a commercial subscription. |
| Hybrid estate with gateways on premises and a managed control plane | WSO2 API Manager | WSO2 describes a hybrid model with a SaaS control plane and on-premises gateways. Confirm the exact hybrid topology and data flows with WSO2 before you commit. |
| Team already running Kubernetes that wants one control plane across gateways | WSO2 API Manager | WSO2 states one control plane can manage WSO2 gateways and third-party gateways including Kong, AWS, Azure and Envoy. Verify the third-party gateway features you depend on. |
| Organization that needs a vendor support contract | WSO2 API Manager with a WSO2 subscription | WSO2 sells on-prem subscriptions with expert support, continuous updates and vulnerability monitoring. MuleSoft support depends on your Anypoint agreement, so compare the scope of each in writing. |
| REST, GraphQL and AsyncAPI APIs in one catalog | WSO2 API Manager | WSO2 documents support for REST, GraphQL and AsyncAPI APIs. Confirm that your MuleSoft assets for each type map cleanly before you plan the move. |
| Mule Community runtime for integration logic while managing APIs separately | Neither alone without a plan | MuleSoft documents that Community runtime lacks some Enterprise features, so confirm which configurations you use. Test your flows on the target runtime before relying on it. |
How the control planes and gateways differ in practice
MuleSoft ties its control plane to Anypoint Platform, so the management layer you adopt is determined by where the runtimes run. Anypoint is delivered through CloudHub and CloudHub 2.0, which MuleSoft operates, through hybrid deployments to Mule servers you manage, through Runtime Fabric on your own infrastructure, and through Anypoint Platform Private Cloud Edition on premises. Each option changes who operates the control plane, where API policies are enforced and which Anypoint features are available. Before comparing costs, map each of your APIs and integration applications to one of these models and confirm with MuleSoft which Anypoint capabilities apply to that model.
WSO2 API Manager separates its functions into distinct components: an API control plane for lifecycle and governance, a gateway for routing, mediation and security, a traffic manager for throttling, and the Publisher and Developer Portal web interfaces. WSO2 describes three deployment patterns on its API Manager page: self-hosted, hybrid with a SaaS control plane and on-premises gateways, and fully managed SaaS, which the page states carries a 99.95% SLA. The practical decision is whether your control plane must stay inside your network. A self-hosted control plane keeps policies and subscriber data on your side, while the hybrid pattern keeps gateways close to your backends. Confirm the SLA terms in writing before relying on them.
A WSO2 control plane can also manage third-party gateways, including Kong, AWS, Azure and Envoy, according to WSO2's description of its API Platform. This matters only if you intend to keep another gateway in service, for example one already running in a cloud provider or a service mesh. If you plan to retire every gateway during the move, it adds no value. For API types, WSO2 API Manager supports REST, GraphQL and AsyncAPI APIs. Confirm that your MuleSoft-published APIs, including any SOAP or event-driven interfaces, can be represented and governed the same way before you plan the policy rebuild.
Capability by capability: what each platform covers
This table compares the API management capabilities of MuleSoft Anypoint Platform and WSO2 API Manager, row by row, and notes when each row matters for your program. Where the supplied evidence does not settle a capability, the cell tells you what to confirm with the vendor before you decide. Read the condition column first, since a row that does not apply to your estate can be skipped.
| Capability | MuleSoft Anypoint Platform | WSO2 API Manager |
|---|---|---|
| Control plane | Hosted control plane through CloudHub or CloudHub 2.0, or Anypoint Platform Private Cloud Edition on premises. Confirm the control plane location for your data residency needs. | Control plane included in the Apache-2.0 product, with self-hosted, hybrid (SaaS control plane with on-premises gateways) and fully managed SaaS options. Matters most when you need the control plane inside your own network. |
| Gateway | Runtime-based deployment on CloudHub, CloudHub 2.0, Runtime Fabric or customer-managed Mule servers. Confirm which gateway policies apply to each runtime. | Gateway for routing, mediation and security, deployable from extracted packages on premises or on Kubernetes through the WSO2 API Platform for Kubernetes. Matters when gateways must sit close to backend systems. |
| Traffic management and throttling | Confirm with MuleSoft which rate limiting and throttling policies are available on each runtime and whether they match your current API tiers. | Traffic manager provides throttling as a named component of the product. Matters when you need per-tier or per-application limits enforced outside a vendor-hosted service. |
| Publisher or API design interface | Anypoint Design Center and Exchange handle API design and specifications. Confirm the export formats available before you plan a migration. | Publisher web interface for creating, versioning and publishing APIs. Matters when API product owners need a browser-based lifecycle tool that stays inside your environment. |
| Developer Portal | Anypoint Exchange acts as the catalog and portal for consumers. Confirm whether your external partners need access to a separate portal tier. | Developer Portal web interface for API discovery, subscriptions and documentation. Matters when external developers or partners must self-serve from a portal you host. |
| REST, GraphQL and AsyncAPI support | Confirm GraphQL and AsyncAPI support and any connector limits with MuleSoft for your Mule runtime version. | Supports REST, GraphQL and AsyncAPI APIs. Matters when event-driven or GraphQL APIs are part of the program, so confirm the depth of support for your specific protocol features. |
| Custom policies and extensibility | Extensibility through Mule runtime components and custom connectors. Confirm the Java version and runtime requirements for custom code before upgrades. | Extensible with custom authenticators, policies and workflows. Matters when your security or approval processes need logic the standard product does not provide. |
| Deployment options | CloudHub and CloudHub 2.0 (MuleSoft-managed), hybrid with customer-managed Mule servers, Runtime Fabric on customer infrastructure, and Private Cloud Edition on premises. Matters for air-gapped or regulated estates. | On premises from extracted packages, managed cloud service, Kubernetes via the WSO2 API Platform for Kubernetes, and a hybrid model. Confirm which combination suits your network boundary. |
| Licensing and support | Commercial subscription from MuleSoft. Confirm the scope of support, runtime tier and any add-on charges with your account team. Matters at renewal or when pricing changes. | Apache-2.0 product. Commercial subscriptions add expert support, continuous updates, vulnerability monitoring and a licensed distribution for commercial use. Matters when you want a vendor support path without a proprietary core. |
Where data and control sit under each deployment model
Each deployment model answers two questions differently: who operates the control plane, and where API traffic and logs are processed. Identity, logging and compliance obligations follow from those answers, so the cards below compare the MuleSoft and WSO2 options on the same terms.
MuleSoft-managed CloudHub and CloudHub 2.0
Both the control plane and the Mule runtimes run in MuleSoft-managed infrastructure. Your application logs, API traffic metadata and identity integration points sit in a vendor environment, so you need to confirm where logs are stored, how long they are retained, and which sub-processors are involved. Ask MuleSoft which regions host each deployment and whether the compliance scope in your contract covers your regulatory obligations. Your auditor will need the vendor's evidence, and DeployOpen can prepare your own controls around that dependency but cannot issue an attestation for the vendor.
Hybrid and Runtime Fabric
The runtimes run on infrastructure you control, while Anypoint Platform still hosts the control plane. Runtime traffic stays local, but deployment metadata, runtime status and management connections leave your network, so firewall rules, proxy paths and outbound connectivity need a written review. Identity for the Anypoint control plane remains with MuleSoft, and log forwarding to your SIEM must be designed explicitly. Confirm with MuleSoft which telemetry is shipped out and which compliance scope applies to the hosted part.
Private Cloud Edition
Anypoint Platform Private Cloud Edition runs the platform on premises, so control plane data, runtime data and logs stay in your data center. Identity, role design and audit trails become your responsibility, and you must size and patch the platform yourself. The air-gapped edition omits some services, so confirm exactly which capabilities are missing before you rely on it for an isolated network. The sibling page on air-gapped alternatives covers that comparison in more detail.
WSO2 self-hosted from packages or Kubernetes
The control plane, gateway, traffic manager, Publisher and Developer Portal all run in your environment, whether from extracted packages or on Kubernetes through the WSO2 API Platform for Kubernetes. Identity can be wired to your own provider, logs go to your own pipeline, and no API metadata leaves the network by design. The trade-off is that your team owns patching, backup, high availability and evidence collection. Confirm with WSO2 which components you must license for commercial use and which open-source components your scanners will flag.
WSO2 hybrid with SaaS control plane
WSO2 hosts the control plane as SaaS while the gateways run on premises, so request traffic and payloads stay local. Metadata such as API definitions, subscriptions, policies and analytics reach WSO2's control plane, which makes that data flow the main item for your data classification and cross-border review. Check how gateway-to-control-plane connections are authenticated, what happens to local gateways during a control plane outage, and what your logs contain before they leave the network. Confirm the compliance scope and data processing terms in writing with WSO2 and your auditor.
WSO2 managed SaaS
WSO2 operates the full API Manager service, including gateways and the control plane, under its managed cloud offering. This model shifts patching, scaling and operations to the vendor, and WSO2 states a 99.95% SLA for its fully managed SaaS deployment. You still own API design, identity configuration and the classification of data passing through the gateways, and you must confirm log retention, tenant isolation, regions and subprocessors. Ask for the service's compliance reports and the contractual scope before assuming any control is inherited.
What drives the cost of each side
On the MuleSoft side, the recurring cost is the Anypoint subscription, which is priced by the deployment model you choose. CloudHub and CloudHub 2.0 are MuleSoft-managed, so the subscription covers the runtime hosting along with the platform. Hybrid deployments to customer-managed Mule servers and Runtime Fabric on your own infrastructure shift the compute bill to you, while Anypoint Platform Private Cloud Edition adds on-premises operation of the control plane. Ask the vendor to itemize the subscription by platform component, by runtime capacity and by support tier, and to state which metering unit applies to each deployment model. Support terms sit inside the same quote, so confirm response targets and whether they differ by environment.
On the WSO2 side, the software carries no license fee under Apache-2.0, so recurring cost is infrastructure, the optional WSO2 subscription and the people who run the gateways and control plane. The subscription provides expert support, continuous product updates, vulnerability monitoring and access to the licensed distribution for commercial use, and it is the line item to scope against your own staffing. Infrastructure follows the deployment you pick: self-hosted from extracted packages, Kubernetes through the separate WSO2 API Platform for Kubernetes, or a hybrid with a SaaS control plane. Ask WSO2 for the subscription scope per component, whether the traffic manager and developer portal are included, and what the distribution terms are for your intended use.
One-time costs land on both sides and are often larger than the first year of licensing. Migrating APIs, policies, client applications and the developer portal means re-creating API Manager configuration, then testing gateway behavior, throttling and authentication against live clients before cutover. Your team or a DeployOpen-style implementation partner will be paid for that work, and it scales with the number of APIs, custom policies and consumer applications. Scope depends on how much of the current estate is inventoried before work starts, so build a catalog first and price the migration against it. Also budget for parallel running and rollback time. Quotes should separate migration, testing, cutover and training, and should state assumptions about the number of APIs and environments.
How a MuleSoft API management exit runs in phases
This sequence moves API management from Anypoint Platform to a self-hosted WSO2 API Manager environment in controlled waves, so each API, application and consumer has a tested path and a rollback option before the MuleSoft control plane is retired.
Inventory APIs, policies and consumers
Your API owners and platform team list every API managed in Anypoint API Manager, the policies and SLAs attached to each, the client applications and their credentials, and the portal pages consumers rely on. Record which gateway fronts each API and which backend services sit behind it. The inventory is complete when every API has an owner, a backend, a policy list and a named set of consumers, and the team has signed off on it.
Export specifications from Anypoint Exchange
Platform engineers download the RAML or OAS specifications, examples and any AsyncAPI or WSDL assets from Anypoint Exchange into a Git repository you control. Some asset types may offer no download at all, so confirm with MuleSoft and in your own Exchange which assets are exportable and record the gaps. The step closes when every API has a specification in version control and a list of assets that must be rebuilt by hand.
Stand up WSO2 API Manager on a non-production track
The platform team installs WSO2 API Manager, which is Apache-2.0 licensed, in a non-production environment inside your infrastructure, choosing the self-hosted, hybrid or managed deployment model that fits your data residency and control requirements. The build requires JDK 21 for the 4.7.0 release, so confirm your Java baseline first. The step is done when the Publisher, Developer Portal, gateway and traffic manager run, and the team can publish a test API end to end.
Recreate policies, applications and portal content
API owners recreate throttling tiers, security and mediation policies, client applications and subscriptions, and the developer portal content in WSO2 API Manager, using the exported specifications as the starting point. Custom policies or authenticators that MuleSoft handled through code or policy extensions need a separate rebuild and review. Each recreated API is checked against its inventory record, and the step closes when every item maps to a WSO2 object or to a documented gap.
Run the WSO2 gateway in front of existing services
The platform team points the WSO2 gateway at the same backend services that MuleSoft fronts today, without changing the services themselves. Integration flows and any Mule runtime work stay in their own migration pages, so this step covers only the gateway layer. Testers run functional, security and load checks against the new path, and the team confirms that logging, authentication and throttling behave as the inventory requires. It is complete when test traffic passes through WSO2 with results documented.
Move consumers in waves with rollback
Consumers are migrated in groups, starting with low-risk internal clients and ending with external partners. Each wave has a written cutover plan, a named owner and a rollback step that routes traffic back to the MuleSoft endpoint. Both control planes run in parallel until each wave has passed its monitoring window. The step closes when every consumer group runs on WSO2 and the rollback path has been tested for each wave.
Retire the MuleSoft control plane
After all consumers have moved and the rollback window closes, the team archives the Anypoint API Manager configuration, exported assets and audit logs under your retention policy, then cancels or reduces the MuleSoft subscription with the vendor. Confirm contract terms and data return obligations with MuleSoft before this step. The step is done when no production traffic depends on MuleSoft, the archive is verified and the decommission is recorded in your change system.
Which path fits: managed, hybrid or self-run
In a managed model, the vendor runs the control plane and the runtime or gateway capacity, and your team focuses on API design, policies and onboarding. On the MuleSoft side, this means CloudHub or CloudHub 2.0, where MuleSoft operates the managed environment. On the WSO2 side, it means the fully managed SaaS deployment, which WSO2 describes with a 99.95% SLA. Your APIs, traffic and configuration pass through the vendor's infrastructure, so the residency question becomes the first item to settle.
- Who operates what: The vendor operates the control plane, the managed runtime or gateway, and the underlying platform. Your team manages APIs, policies, applications and access.
- What data leaves: API payloads, logs and configuration are processed in the vendor's cloud. Confirm the regions, subprocessors and log retention in writing.
- Upgrade responsibility: The vendor schedules and applies platform upgrades. Ask which maintenance windows apply and whether you can defer or test changes.
- Skills needed: API product management, policy design, identity configuration and integration design. Fewer staff need Kubernetes or database operations.
- Cost driver: Subscription tiers and usage metrics recur, and they grow with traffic and environments. Ask how each metric is counted.
Check the data residency terms and the contractual SLA before assuming a managed model fits a regulated workload.
A hybrid model keeps the gateway or runtime inside your network while a vendor-hosted control plane manages configuration and visibility. MuleSoft documents Runtime Fabric on customer-managed infrastructure, which lets you run Mule workers in your own environment. WSO2 describes hybrid deployment with a SaaS control plane and on-premises gateways. Traffic stays local, but the management plane still depends on the vendor's service.
- Who operates what: You run the gateways or runtimes and the infrastructure under them. The vendor runs the control plane and its portal or console.
- What data leaves: Configuration, metadata and some telemetry reach the vendor's control plane. API payloads usually stay in your network, but confirm this for each feature you enable.
- Upgrade responsibility: You patch and upgrade the data plane components on your schedule. The vendor upgrades the control plane, which can change behavior you depend on.
- Skills needed: Container or cluster operations, network design for outbound connectivity, and certificate and secret handling, in addition to API design skills.
- Cost driver: You pay for the infrastructure and for the operations time to run the data plane. Recurring subscription costs still apply to the control plane.
Ask the vendor which control plane data crosses your boundary and whether a connection loss stops new deployments or only management actions.
In a self-run model, your team installs, operates and upgrades the full stack inside your own infrastructure, including the control plane, gateway, developer portal and supporting services. MuleSoft offers Anypoint Platform Private Cloud Edition on premises, which runs the control plane in your environment. WSO2 API Manager supports on-premises installation from extracted packages and on Kubernetes through the WSO2 API Platform for Kubernetes. Data stays in your environment by design, and the operating burden moves to your team.
- Who operates what: Your team operates every component, including databases, certificates, backups, monitoring and access control.
- What data leaves: Nothing needs to leave your environment for normal operation. Confirm any licensing check or update channel that requires outbound access.
- Upgrade responsibility: Your team plans, tests and applies each upgrade. WSO2 API Manager 4.7.0 was released on April 29, 2026, and building it requires JDK 21, so confirm the Java and platform prerequisites for each version.
- Skills needed: Linux and Java operations, database administration, Kubernetes if you use it, and security hardening. Plan for on-call coverage.
- Cost driver: Infrastructure, staff time and upgrade testing recur. WSO2 commercial subscriptions add expert support and continuous updates, and they are optional for the self-run model.
Confirm the support terms, upgrade path and staffing plan with each vendor before you commit to a self-run model.
Questions buyers ask before switching from MuleSoft
What does a switch from MuleSoft to WSO2 API Manager cost?
The cost splits into components that are paid for by different parties: the MuleSoft subscription you stop paying, the infrastructure you run for WSO2 API Manager and its gateway, the implementation work to recreate policies, applications and the developer portal, optional WSO2 subscription fees for support and updates, and internal engineering time. Most of the one-time cost sits in rebuilding API Manager configuration and testing gateway behavior against existing clients. Recurring cost is infrastructure, operations and any subscription you choose. Ask for a quote that lists each component separately, states which items are one-time and which recur, and names the policies, APIs and environments in scope. Estimates should follow from the number of APIs, policy types, environments and deployment topology you select, not from a flat number.
How long does moving API management off MuleSoft take?
The timeline is set by the number of APIs, the complexity of their policies, how many client applications and portal users must be moved, and how many environments need parallel running. Gateways in front of production traffic usually need a staged cutover, so plan for a parallel period in which MuleSoft and WSO2 both serve traffic. A fixed-scope engagement sets the duration in writing before work starts, so ask for a schedule tied to named deliverables. Run a short pilot on a low-risk API first, then use what it reveals to size the rest. Also check whether the move coincides with other MuleSoft changes, such as runtime upgrades, because shared dependencies can extend the plan.
What does our team need to provide during the migration?
Your team needs to supply the inventory and ownership of APIs, access to Anypoint Exchange specifications and API Manager configuration, the list of client applications and their credentials, and the networks, identity provider and Kubernetes or virtual machine capacity where WSO2 will run. Engineers familiar with the existing policies and traffic patterns must confirm expected behavior, and a security owner should approve authentication, throttling and logging changes. Decide early who will operate the platform after go-live, since that person or team needs access during testing. Ask any implementation partner to name the buyer-side roles they expect, and to list the items they cannot complete without your input.
Can our own team migrate from MuleSoft without outside help?
Yes, a capable platform team can do it, but the decision depends on how many APIs you run, how many custom policies exist, and how much time your engineers can give without disrupting other work. Teams that have run gateways, Kubernetes and identity integration before tend to handle the core work in-house, while teams new to API lifecycle tooling often benefit from outside help with the design and cutover. You can also split the work, keeping routine configuration in-house and buying fixed-scope help for the gateway design, security testing and cutover. DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms in your own infrastructure under a written scope, so you can ask for a partial engagement covering only the parts you need.
Does WSO2 API Manager require a paid subscription?
No. WSO2 API Manager is licensed under Apache-2.0, so the open-source software can be downloaded and run without a subscription. WSO2 sells commercial subscriptions that add expert support, continuous product updates, vulnerability monitoring and access to a licensed distribution for commercial use. Whether you need those depends on your risk tolerance, support expectations and internal capacity to track fixes. Before deciding, confirm the license terms for your intended use with WSO2 and your legal team. In a quote, ask which items are included in the open-source path and which require a subscription, and what each option costs in writing.
Do the 4.7.0 release and its JDK 21 requirement affect planning?
Yes, they affect the build and the platform baseline. WSO2 API Manager 4.7.0 was released on GitHub on April 29, 2026, and the repository notes that building it requires JDK 21. Your build pipeline, container base images and runtime images must therefore support JDK 21 before you compile or deploy the product. Confirm which release your team will standardize on, test custom authenticators, policies and workflows against that release, and schedule time for a Java runtime upgrade if your current images do not include it. Ask any delivery partner to state the release and JDK version in the scope document, so that the build environment is part of acceptance testing.
Can a WSO2 gateway protect APIs that are not built on Mule?
Yes, the WSO2 API Manager gateway handles routing, mediation and security for the APIs it fronts, and the repository describes support for REST, GraphQL and AsyncAPI APIs. It does not depend on the API being built on Mule, so services written in other frameworks can sit behind it. Check each backend for its protocol, authentication method, header handling and expected payload size, because those details decide the mediation and security policies you need. Also confirm how WSO2 will reach services in private networks or other clouds. Ask for the list of backends, protocols and policies that the design covers, and for the test evidence that each path works under load.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a MuleSoft vs WSO2 API Manager decision, we start from your API inventory, deployment constraints and support obligations, then build only the part of the programme you agree to in writing.
How we scope
- We inventory APIs, consumers, policies, deployment targets and the MuleSoft runtimes and control plane features in use.
- We record which WSO2 API Manager components, deployment model and gateway placement fit your network and data residency rules.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We install WSO2 API Manager from your chosen distribution, configuring Publisher, Developer Portal, gateway and traffic manager in your environment.
- We recreate policies, throttling tiers, OAuth2 applications and REST, GraphQL and AsyncAPI definitions, then test each against documented behavior.
- We run security testing on the gateway and APIs and prepare controls and evidence for your compliance assessments.
How we hand over
- You receive architecture, configuration, runbooks, backup and upgrade procedures written for your own operations team.
- We walk your platform and security staff through the gateway, control plane and developer portal before cutover.
- Compliance evidence is organized for your independent auditors, since DeployOpen prepares evidence but does not issue audit reports.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the initial work.
- Vendor subscriptions for WSO2 support and continuous updates are a separate purchase that we can help you size and confirm.
- Ask your WSO2 contact to confirm current licensed distribution terms and support scope for your deployment before signing.
