We just raised a $30M Series A: Read our story

Mulesoft Anypoint API Manager OverviewUNIXBusinessApplication

Mulesoft Anypoint API Manager is the #3 ranked solution in our list of top API Management tools. It is most often compared to Microsoft Azure API Management: Mulesoft Anypoint API Manager vs Microsoft Azure API Management

What is Mulesoft Anypoint API Manager?

API Manager is a component of Anypoint Platform for designing, building, managing, and publishing APIs. Anypoint Platform uses Mule as its core runtime engine. You can use API Manager on a public cloud, such as CloudHub, a private cloud, or a hybrid. A hybrid deployment is an API deployed on a private server but having metadata processed in the public cloud.

Mulesoft Anypoint API Manager is also known as Anypoint API Manager.

Mulesoft Anypoint API Manager Buyer's Guide

Download the Mulesoft Anypoint API Manager Buyer's Guide including reviews and more. Updated: October 2021

Mulesoft Anypoint API Manager Customers

Coca-Cola, Splunk, Citrix, UCSF, Vertu, State of Colorado, National Post, TiVo, Deakin, LLS, Oldcastle Precast, ParcelPoint, Justice Systems, Ube, Sumitomo Corporation, PacificComp, University of Witwatersrand, Groupe Initiatives, Camelot, Panviva

Mulesoft Anypoint API Manager Video

Pricing Advice

What users are saying about Mulesoft Anypoint API Manager pricing:
  • "I'm unsure about licensing costs because I'm not the person who handles this. But, ballpark, it's probably somewhere around $300,000-$400,000 or something like that."
  • "The licensing fees are approximately $80,000 USD per year and there are costs for additional functionality, as well as premiums for connectors to systems such as Oracle and SAP."

Mulesoft Anypoint API Manager Reviews

Filter by:
Filter Reviews
Industry
Loading...
Filter Unavailable
Company Size
Loading...
Filter Unavailable
Job Level
Loading...
Filter Unavailable
Rating
Loading...
Filter Unavailable
Considered
Loading...
Filter Unavailable
Order by:
Loading...
  • Date
  • Highest Rating
  • Lowest Rating
  • Review Length
Search:
Showingreviews based on the current filters. Reset all filters
MA
Senior Architect at a consultancy with 1,001-5,000 employees
Real User
Good API management and an excellent enterprise platform

Pros and Cons

  • "The ESB, the enterprise service bus is what we primarily use. In addition to that, the API management. These are the two tools which we have been using extensively. The enterprise platform."
  • "Rather than focusing on numbers, they should focus more on the customer support service."

What is our primary use case?

We do business with a lot of other vendors and customers. Our main core business is to lend loans and lease furniture. In this context, we have to create partners and we have to do multiple transactions with multiple vendors and multiple facilitators. In this venture, we consider APIs the best, and our most sophisticated medium to communicate with other partners and other lenders at home and elsewhere.

We want APIs to be the most sophisticated and more robust. REST APIs are the core in this area. We have been using Mulesoft specifically to create our REST APIs, enlarge them, and also expose the endpoints to our vendors so that they can use them. Internally, we have been using the APIs extensively for all of our internal application communication. Raw ping and workflow and all those things. We use this Mulesoft extensively for API management, REST API stack, and also for the workflow.

How has it helped my organization?

We're going to have a task with another bank who will be lending us the loan or they will be giving us some money for us so that we can lend this to double customers and expand into different industries. We're doing the business directly with those banks who we're really trying to work with, and doing joint collaboration so that we can lend loans to the customers, the retail customers.

In this context, we have to collaborate with those banks in a sophisticated way. Few banks are very, very advanced in the necessary technology. We propose of them usage of the APIs. The advanced banks already have the APIs. That kind is a very smooth transition, but the banks whom we're working with, a couple of small banks, don't have the API stack. Whatever the legal systems they have, we enforce them to convert those existing legacy systems as the APIs, and also those other REST APIs, and we can have a smooth transition.

The initiative went very well, and they're very happy with a lot of the tasks we have been doing. Now, they have extended the business. They want to censor their existing systems. They want to expand their system. This is one of the examples of how the solution has improved our organization. In this juncture, we place Mulesoft as one of the core solutions in our organization API stack. Communicating with one application and other application, or the validation of the loan ID or the validation of a customer or generating the customer base, whatever it is. For the day to day tasks, we use API systems only. API is one of the most crucial parts of the IT initiatives which are going down in our office on a day to day business.

What is most valuable?

The ESB, the enterprise service bus is what we primarily use. In addition to that, the API management. These are the two tools which we have been using extensively. The enterprise platform. 

What needs improvement?

I don't think that it's a negative, but one of the biggest things is this: when they were merging with Salesforce they never said anything about that, they did not give any positive or negative news. They were just silent about that. I think there's something clandestine has been happening over there. I'd like to know what is the future roadmap of Mulesoft is after it got merged with Salesforce.

Nobody is giving proper information because I called a couple of Mulesofters and they're not giving information. I don't know whether they're naïve, or they don't want to disclose about whatever it is. That is the first thing they have to address. If they don't address probably they'll lose a lot of their customer base, so they must have to address that.

Also, in regards to near future resellers - they have to increase the capabilities for the Kubernetes, for continuous integration. Mostly you can call the DevOps. Still, now there are some gaps out there they have to address for the DevOps capability like continuous integration exclusively for the Kubernetes and Docker. They say that they have complained, but I asked for realistic examples and concerns, and still very few things have to be addressed. That is the first thing that they're going to have to address probably. I had some discussions with those people there. 

The second thing is they're mostly focusing on the security. I think security plays a vital role in going forward in regards to API stack. Not only for the API stack, but also for the enterprise service capabilities in which security plays a vital role. They're adding a lot of security capabilities over there. That is also one other thing I hope they continue to work on in the future.

In addition to that, they're going to add a lot of additional plugins. Plugins in the sense they compiled from Salesforce and a couple of other applications, but they have to address a few more applications. They should take a cue from Webex Desk. If everybody is using Webex Desk, every third-party application, and they want to communicate with Mulesoft, they don't have any plugins. They have worked a lot on the plugins. 

Lastly, regarding the streaming of data. In terms of streaming of data, I don't rely on Mulesoft. Whenever they do new data streaming or any streaming, the conceptual architecture connects to us, like data streaming and also for video streaming. Because the streaming capabilities are very minimal they don't stream. The capability was not there.

I heard that they're addressing this issue, probably in the next couple of months. They're going to address this issue. If they are, then I think this will be one of their biggest achievements. I think it will impact their business and also their challenge. It will impact the whole pipeline also, so they can accumulate more customers.

For how long have I used the solution?

I've been using the solution for two years.

What do I think about the stability of the solution?

The solution is a stable one. But as the API stack has been increasing, whenever the new stack is saving, at the end of the day we have got our own Kubernetes to connect the APIs completely. The capacity has been increasing day by day, so we have to increase the capacity. We have to do so regularly. At least quarterly, we have to do some capacity planning for that. It's not cost-effective and it's got a cost impact too. We have to invest something around a few thousand dollars to enhance this capability.

Their method is not cost-effective. It's some costly, but for the performance and the overall customers who are using our APIs and what we're doing internally, we're happy with that. The organization is ready to bear that cost, but our only concern is they have to address our tasks. Whenever we seek their assistance they should address our task quickly. They should not insist to us that somebody from there will show up and do some due diligence. I think that is not required for all the customers because we feel that we're mature enough to tackle our own Mulesoft, whatever the day to day usage is concerned. We don't need their assistance anymore.

If we need them we will definitely put in some clear understanding that we need their assistance. But in future, we might only need assistance for Docker and Kubernetes because we're having some challenges over here. Or, in relation to security, we might need their assistance. 

What do I think about the scalability of the solution?

It's highly scalable. It's a good technology. We have to increase and plan the capacity in advance. We have to execute our IP partly with other business because our business is very aggressive and very highly patent-oriented. To meet our business expectations, our IT stack has to be more efficient and more robust. We have to scale our business acumen in a very aggressive way. At this juncture, what we have to do is make our technologies or our applications more scalable and more persistent and continuously integrated. At this point of time, the features are being generously added. But there should give some flashpoints or something like that because the capacity has been missing.

I'm not sure whether we don't know how to configure those features or not. We're naïve about those features or maybe Mulesoft does not have them, but whenever we end up with this capacity, it has been going down, then we have to do a lot of due diligence and we have to do some capacity planning, which means we have to do some fibering, which has happened three to four times over a period of the last two years. We want to reduce that because it might impact our business. Because we have aggressive targets and loan book should be more, or I'll say we're expecting more from the customers.

At this point in time, our API stacks have been more supportive and more resilient. Mulesoft never gave any problem, but to scale up to this kind of capability, yes, we have to do some fibering but everything is going well, fortunately.

In terms of usage, I can say 1,000 to 2,000 users on day to day basis, because we have got a very big call center. They're not aware that they're using these APIs, but previously the APIs randomly show. I can say around 2,000 users are there. I'm talking about business users, not technical enrollment.

We want to scale up the user count, and want to increase our loan book on a regular basis. We're enhancing and emphasizing most on our digital capability so that a lot of customers who are entitled to and get to enroll as our customers, will be rendered loans. They will get paid online. Lots of things are new here. Innovations are being added and getting added in the near future. The customer base will also be increasing, so to make this happen, we have to scale our capabilities, and we have to meet our increasing customer base.

How are customer service and technical support?

I don't oversee the Mulesoft activities on a day-by-day because I work on the enterprise architecture security. We rarely go and focus on Mulesoft but whenever we ask them any questions, rather than addressing the question, they completely answer in such a way that they will do some due diligence. Somebody will show up at our premises, and they'll send some statement of work or something like that.

They want to turn every question into a business. I understand business is not a charity. But at least, being customer service, something you have to understand through the customer perspective, is that customers are expecting to do some due diligence and that you understand the customer complaint correctly, and then address their concerns. If there really is any business potential there, then you can address that.

Rather than jumping into the business wagon initially, they should understand the concern. They should understand the issue, and they try to address that, then if they really feel that there's business, or they have a business opportunity out there, they can capitalize that. Nobody is refusing that.

Rather than focusing on numbers, they should focus more on the customer support service.

Which solution did I use previously and why did I switch?

I don't think the company had a prior solution. Our IT stack has been matured from 2015 onwards. Gradually it's getting scaling up. In 2015 our company used to work on spreadsheets. IT stack was being set up in 2015. In 2016, we censored all our spreadsheets and all those things, and we brought Salesforce into our company so that all the call centers on the branch associates who disperse the loans, who grant and pursue the loans have been using that. Once the Salesforce has been established, gradually we found that API as one of the most innovative thing.

We brought APIs. First, initially we did some Java-enabled APIs, but we found that it was going to be consuming a lot of time and energy, so thought rather an API management product may be viable. We brought Mulesoft. I think somewhere around the beginning of 2017 we brought Mulesoft. 

How was the initial setup?

Before joining the team, most of Mulesoft had already been initiated. But what I realized was that most of my colleagues and supervisors don't have the API experience. Secondly, even though they have the experience, Mulesoft gives a lot of tutorials on their website, but most of them are not self-explanatory. They insist that customers find a Mulesoft expert, mostly because they seek the assistance from the Mulesoft consulting group to come on board and do some due diligence, and then you will hear, "Somebody will come and install it." That is what they have been doing over a period of time. I think that this process is still continuing. I don't think that's been stopped.

So, we had a challenge with configuring initially when we installed Mulesoft, but you really have to understand the concepts of Mulesoft, and if you follow the regulatory and follow the manual if you have a little bit of experience, I think it's not a big deal. You can configure Mulesoft very efficiently.

In terms of the implementation strategy, initially, we were blindly following whatever the Mulesoft consultants said. They had been talking about creating your architecture, and this is what was involved in the deployment methodology. For almost one and one and a half year, we have been following them. Lately, we've changed the strategy, and we've customized our deployment strategy. We merged with Kubernetes, Jenkins, and we have JIRA inside our organization.

To make our customization comply with Docker and Kubernetes, it took some amount of time, but it consumes a bit amount of time to configure all these items within the Mulesoft and run it. It took around three to four months of time to complete this exercise because we struggled with the documents. They're not as explanatory as they should be. Also, whenever we tried to reach out the Mulesoft, they said that they would come out and they would do it, and they would do some consulting. But they would charge more. To avoid extra cost, we did our own exercise, and frankly speaking, the tutorials are not self-explanatory. The majority of this Docker and Kubernetes is not as mature as it should be when compared with Apigee. Apigee is very fast. 

Going forward, we're going to migrate all of our applications to Azure. That has also hasn't been addressed yet. But the concern has already been raised. I don't know when they're going to address it. Yeah, these are the challenges. The tutorials, whatever they give, is not self-explanatory. It takes a lot of time to build any new initiative as far as Mulesoft is concerned.

We already have our full development center. The email team is there who've been supporting us. We have an internal workforce in there we've been doing. Along with me, there are two more architects who report to me. They do their job, and one dedicated Mulesoft integration architect, I can say the solution architect, but she supports the Mulesoft activities. The Mulesoft delivery manager is there. They're checking this challenge. They're accepting this challenge, and we're looking all those things.

What about the implementation team?

We had help with implementation by Mulesoft.

What was our ROI?

I cannot give you any figures because frankly speaking we never measured anything, but I can say that it has made a significant contribution. 

What's my experience with pricing, setup cost, and licensing?

I'm unsure about licensing costs because I'm not the person who handles this. But, ballpark, it's probably somewhere around $300,000-$400,000 or something like that.

What other advice do I have?

There are a lot of products available on the market. Mulesoft is very good. It's an amazing product, no doubt about it. There's quality in the standard version, and the acumen and the technology are very good. What I want to tell them is before going for Mulesoft to consider Apigee. There are a couple of open-sources out there. What I would suggest is to not go blindly with the product stack. If you want to use the APIs, understanding of APIs are must because no company is independent. They have to do business with other companies. API is one of the most standard and robust methodologies to communicate with other business and do the business for the day to day transactions. And API is one of the most friendly approaches.

In this juncture, before going with an API management solution, understand whether you can create your own in-house APIs and see if you can leverage on that based on for the timelines and the costs. Then you can examine your goals because not every company is the same. Product due diligence is must especially when you do business with huge numbers of customers. For those kinds of numbers, you have to do an aggressive and some scale due diligence before going for the product.

My suggestion is to do due diligence and find the registered products, which are capable, and customizable for your requirements. Then you go with that product. As far as Mulesoft is concerned, yes, most of the small-scale and medium-scale customers, yes, it is one of the best tools. But when you scale up for large-scale customers, it has got those capabilities, but the Mulesoft team is not addressing those capabilities.

With Apigee, they address the concern and they go after a solution, and have a different approach, whereas, with Mulesoft, they insist the customers follow their methodology, which may or may not be suitable for all the lines of businesses. But when you come to the Apigee, they tailor to vendors, they customize themselves and act as the business owner, and they make for the business one of the best solutions. That's the difference.

However, I'm sure that what Apigee can do, Mulesoft can do better. But they have to address these concerns. To address these concerns, they should publish more articles, and the tutorials should be updated. The tutorials and the knowledge base should be updated thoroughly, and it should be made available for all the customers, as well as new learners.

Generally, they can make their product more sellable. It should not be hidden. I feel that is one of the challenges they have been facing, and they're not addressing that over a period of time.

I would rate this solution at 8 or 8.5 out of 10.

Which deployment model are you using for this solution?

Private Cloud

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Disclosure: I am a real user, and this review is based on my own experience and opinions.
NE
Global Head of Digital Cloud & Platform Services at a financial services firm with 10,001+ employees
Real User
Top 20
A mature solution with good policy management but can be quite expensive

Pros and Cons

  • "Technical support has been helpful."
  • "The initial setup, if you go back three or three and a half years, definitely, for us, was complex."

What is our primary use case?

We primarily use the solution for our APIs. We are moving from monoliths to API architecture and we have approximately 10,000 to 12,000 APIs across banks, which are hosted on this product. It also provides us a gateway service to ingress the traffic as well as whole policy management where stuff is taken care of from the PC Any Point. It also has some API-level runtime policy management, which we use.

What is most valuable?

The gateway service to ingress the traffic is great. 

The whole policy management has been great. 

It has some API-level runtime policy management, which is useful for us.

The solution is extremely mature.

You can scale the solution.

What needs improvement?

The only drawback is that, due to the fact that we are going into a completely API structured way of working, it is very tightly coupled with the vendor solutions. For example, the run times. What happens is when you have to do a change or you have to do anything, you have to rip off all the APIs and rebuild it.

If you see the features, they are really good in one sense, however, they have a certain drawback when you get into the operational way of working. We definitely need APIs to have policies at runtime. They provide a feature where there's a lot of policy on authorizations, however, the only problem is the runtime. 

When the runtime upgrades, we have to basically publish a new build pack and then do all the rebundling. When we were 2000, 3000 APIs, it was okay. However, when you start going up to 10,000 to 12,000 APIs, it was too much.

The whole cost is an issue. Deploying to production is not a very easy job in that bank as we go through the whole change process. The whole tight coupling of the product is a problem. 

As a bank, we didn't want to take any risk of getting so much tightly coupled with any vendor product. It should be replaceable as required. That's the only reason we are now changing products.

The upgrade is a very messy process. Mule 3.X to 4 or 4.2 requires you have to rewrite the APIs. It is not just upgrading the build pack with a runtime. That is something that gets us scared a lot. They came back and told us when we move to four run times we had to upgrade. You had to rewrite the APIs. The APIs cannot just work in a straightforward manner. There is a lot of change and we have approximately 5% Mule APIs and then the rest are boot APIs. While, now, that means 5,000 APIs need rewiring, after two years, we might have 20,000 APIs. They should have a proper way of having backward compatibility.

The initial setup is complex. 

If they are going with that control pane in a cloud, which is a very good feature and it is a managed service, they should give it 24/7, 100% uptime. They should also spin it across multiple regions. Currently, they are just the US and the EU is coming up. However, they should add, for example, China or Asia, et cetera. We operate in more than nearly 40 countries. Every country has a lot of its own governance and compliance and regulatory checks or some, where we cannot host to the cloud.

For how long have I used the solution?

We have used the solution for three and a half to four years at this point.

What do I think about the stability of the solution?

We have a massive set up and definitely, there are sometimes a few issues, which come here and there, however, we manage to build a resiliency inside that.

What do I think about the scalability of the solution?

We have scaled from a few hundred APIs to 10,000 APIs. Just on the retail part, the gateway service runs more than 125 million transactions per day. It's a huge setup we have. 

The only drawback back again is that their gateways are pretty heavy on hardware. Therefore, we spend a lot of money on the hardware. If you compare with Kong, Kong actually can just replace everything with two VMs. We have 500 VMs running for us as gateways. It has scalability, however, it will cost you, which is a problem.

How are customer service and technical support?

Technical support has been helpful. There were also people embedded in my team.

Which solution did I use previously and why did I switch?

We are migrating from Mule to Kong now. We just have signed the contracts and we are basically getting the thing set up. It is a big project and it is going to take maybe another three to four months to roll it out to non-production and maybe another five months into production as we need to get everything in compliance and clear.

How was the initial setup?

The initial setup, if you go back three or three and a half years, definitely, for us, was complex. As a bank, we run through a lot of securities. Since then, they have matured the process. They worked with us, to do some upgrades. Kong also will have to do a few things for us, once we migrate. Currently, we are already finding some issues, which Kong is trying to help us and fix it. However, Mule took a bit of time to set up. If we were to do it now, it would be easy. 

They have come up with API management and cloud hub, which is the manual service. We have not used it much, however, there are some use cases from a different part of the bank that tried it out. It's a good option as you get rid of the whole operational management side of the whole control pane. The control pane we are running is a PC 1.7.3 or something, which is old and coming up on the end of support.

The cloud hub may solve the problem of the control pane, even though they have some issues with the maintenance windows and stuff. Due to the fact that the policies are cast in the control pane, and run times can struggle, if the control pane goes down or needs maintenance because we need a hundred percent of availability in some way or other, it needs to be resilient also. The maintenance windows can cause trouble for us in banking.

What's my experience with pricing, setup cost, and licensing?

We originally signed a three-year licensing agreement.

There's room for improvement on the licensing. They could do better.

What other advice do I have?

I'm not sure I would recommend the solution to everyone. The approach we have taken is, we have moved out completely from the Mule APIs to Spring Boot APIs. We will decouple the whole vendor locking and stuff. However, it depends on the use case for each company. There is no good and bad product. These guys are both very mature products. Depending upon the use case, you will have to consider how you will handle scaling, for example, or other challenges. 

Everything has a drawback and plus and minus, so pros and cons. Even Kong is a new product. It may be a good performer, and very lightweight, with low infrastructure needs. We don't know. 

Our cyber is very strong. Like us, people will have to evaluate, depending upon their use cases, all the pros and cons of security and see how it fits. 

I'd rate the solution at a seven out of ten.

Which deployment model are you using for this solution?

On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
Learn what your peers think about Mulesoft Anypoint API Manager. Get advice and tips from experienced pros sharing their opinions. Updated: October 2021.
540,984 professionals have used our research since 2012.
SS
SVP - API integration, Fintech, Solution Architect, Delivery and Digital Lending at a financial services firm with 10,001+ employees
Real User
Good runtime fabric and API management, but doesn't scale well

Pros and Cons

  • "The stability overall has been pretty great."
  • "We find that the enterprise level is lacking scalability."

What is our primary use case?

We primarily use the solution for API management.

What is most valuable?

Their gateway is great. They have a pay manager gateway which I find very interesting. 

We like their API manager.

Their RTF, runtime fabric, is very useful.

The stability overall has been pretty great.

We didn't have any issues with the initial setup.

Technical support has been very helpful.

Their ability to observe is good.

What needs improvement?

Some items are not ideal. For example, they should for sales management, they need better performance in the core processing.

The IO blocking isn't ideal.

We find that the enterprise level is lacking scalability.

We have some hundred Linux boxes and 400 or so APIs and for scaling, we are facing challenges. However, we haven't yet compared it to other ESBs, and therefore it's possible that all ESBs are limited in the same way.

They're in the process of evolving right now. There are many changes on the horizon that may prove to be interesting. For example, we've implemented CI/CD and now it's my understanding that the graph scale's also coming. 

For how long have I used the solution?

I've been using the solution for four years.

What do I think about the stability of the solution?

The stability of the solution is pretty good. There are no bugs or glitches and it doesn't crash or freeze. It's reliable. 

What do I think about the scalability of the solution?

The scalability is lacking. We're not sure if it's just this solution or ESBs in general, however, we've had trouble scaling as we need to.

We have about 100 users on the solution currently. They are mostly tech leads, senior developers, and architects.

How are customer service and support?

Technical support has been great. If you raise a ticket, then they respond on the basis of the severity of the issue, the criticality of the issue. They attend to the call really quickly. We've been happy with the level of support on offer.

How was the initial setup?

The initial setup is very straightforward. We didn't have any issues at all. It's simple and easy to implement and not overly complex.

We have 30 to 50 people that comprise a support team that can help handle any maintenance issues. 

What about the implementation team?

We did have assistance from MuleSoft support.

What's my experience with pricing, setup cost, and licensing?

I don't have any visibility on the licensing and therefore cannot speak to the exact cost of the product.

We are working with a platinum tier and have an unlimited core. It's my understanding is that there are no additional costs beyond the licensing fee itself. 

Which other solutions did I evaluate?

We've gone live with MuleSoft and I have been comparing it with TIBCO or Dell and IBM products. If it's threat management that can be done concurrently across platforms, maybe it can be performed better. However, I've heard TIBCO is not evolving at this time.

I was exploring other options for my own knowledge and understanding as I am looking for a job change. People not only use Mulesoft, and companies want to have knowledge in two to three platforms. I'm just comparing Mulesoft with IBM ESB, Oracle, and a few other products. 

What other advice do I have?

We're just a customer and an end-user.

Previously, a Mulesoft community edition was available. We started using Mulesoft's community version. We were exploring some ESB in our organization four years back. We started using MuleSoft as we've got Salesforce. At that time, Mulesoft was not yet acquired by Salesforce and that's why we went with the community edition. It was good. It was free. Then, slowly, we purchased some courses and Mulesoft was more connected to Salesforce. Now also Salesforce is there and AWS is there and it's more well-known and integrated. We thought it would help us due to its growth.

I'd rate the solution at a seven out of ten. It's a product that's still evolving. 

Which deployment model are you using for this solution?

Hybrid Cloud
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
MD
CEO & Co-Founder at a computer retailer with 11-50 employees
Real User
Top 20
Vendor-free, well implemented and managed, with good documentation

Pros and Cons

  • "The documentation is great; it is always up to date and well-presented."
  • "The initial setup is very complex."

What is our primary use case?

We are solution integrators and this is one of the products that we implement for our clients.

It is used for integrating and logging data from legacy systems to make it available for other systems within the IT infrastructure in the enterprise. It is also used for data migration and making it available for customers, devices, services, and so on.

Essentially, it is for data governance and API governance.

What is most valuable?

The most valuable things about this solution are how it is implemented and managed, and that it is vendor-free.

For system integrators and analysts, it is pretty clear how this system works.

The documentation is great; it is always up to date and well-presented. If any details are missing then there is a blog available that contains a lot of details. There are also channels on YouTube to help you better understand the solution and what some of the processes look like.

What needs improvement?

The initial setup is very complex.

For how long have I used the solution?

I have been using the MuleSoft Anypoint API Manager for two years.

What do I think about the stability of the solution?

This solution is stable but it is important to remember that it is the glue between other systems that might have issues with instability. The MuleSoft platform connects all of the systems together and collects data from different sources to create new types of data and new statistics.

In general, it is used on a daily basis and most of the time, it's stable.


What do I think about the scalability of the solution?

Scalability is perfect. The API Manager is used by large clients and is made to be scaled.

How are customer service and technical support?

I have never been in contact with technical support. It is not often that something goes wrong.

Which solution did I use previously and why did I switch?

I have worked with other API management systems such as those by Kong and Tyk. Each vendor has its own functionality that you need to know about so that you can work with effectively.

How was the initial setup?

The initial setup is complex compared to solutions such as Kong or Tyk. There are many things to keep in mind concerning configuration, features, and different options for different systems. I would say that overall, it is very complex.

When all of the requirements are well defined, well described, clear, and consistent, the implementation is fast and can be done in a matter of weeks.

Maintenance only needs to be done when there is a change in business or operational processes. Also, there are some updates that are required but usually not many.

What's my experience with pricing, setup cost, and licensing?

The licensing fees are approximately $80,000 USD per year and there are costs for additional functionality, as well as premiums for connectors to systems such as Oracle and SAP.  You're not obligated but it is better to buy premium and official connectors, although they cost approximately $25,000 per year.

What other advice do I have?

My advice to anybody who is considering this solution is to first make sure that there are no alternatives that are most cost-effective, such as open-source products. Many of them are much cheaper but are still able to provide the same relevant functionality and the same level of data security.

I would say that MuleSoft has the best API manager but it is not the cheapest one and as such, not for everybody. It is not everyone who needs to connect expensive systems together.

I would rate this solution a nine out of ten.

Which deployment model are you using for this solution?

Hybrid Cloud
Disclosure: My company has a business relationship with this vendor other than being a customer: Partner
Tolulope Adeniji
Technical Lead - Integration/Middleware at a financial services firm with 10,001+ employees
Real User
Top 5Leaderboard
Good stability with responsive technical support and lots of connectors for backend applications

Pros and Cons

  • "The solution has been very stable."
  • "Their analytics needs a lot of improvement. It's really lacking right now."

What is our primary use case?

We use it for integration with backend applications. We use it to connect to applications like SAP databases, or Infomatica Collibra or MongoDB, and some other backend applications.

What is most valuable?

One good thing about MuleSoft, is that they have a lot of connectors to those backend applications. We don't really need to write code to be able to connect to a database or to connect with SAP. You just need credentials and the connectivity details. Most of the development of what we do is just drag and drop. They're able to connect with applications using standard connectors that are provided by ESB, by MuleSoft.

The initial setup is very straightforward.

The solution has been very stable.

Technical support has been great.

What needs improvement?

If you want to see the full-fledged functionality of their analytics engine, you have to pay separately for that. It's not the case with, for example, Apigee. That is out of the box. For MuleSoft, then you need to specifically pay an additional licensing fee be able to get the benefits of the analytics.

It would be ideal if they had full-fledged features out of the box versus having to pay for them separately. 

For how long have I used the solution?

I have five years of experience using this product.

What do I think about the stability of the solution?

The product offers a very stable platform. We've had a couple of issues, however, it's a stable platform overall. Due to the API, there may be some buggy codes. We have not had any major issues, and, if we do, the technical support is very responsive to our queries.  

How are customer service and technical support?

Technical support has been excellent. Whenever we've had to contend with a bug, they have been very helpful at assisting us. We're very satisfied with their level of service. They are extremely responsive and very knowledgeable.

How was the initial setup?

The initial setup is very straightforward. It's much more straightforward, that, for example, Apigee, which is more difficult to execute.

What was our ROI?

The product added a lot of value to the organization. Usually, all integrations are point to point. For example, if Informatica needs the information from SAP or SAP from PeopleSoft,  they have point to point connection. Due to the fact that we are able to handle connectivity using MuleSoft, it's actually reusable for applications. Therefore, once we connect to SAP, we don't need to deal with that connectivity again. Any other application that needs to connect to SAP reuses the same API that we have developed on this platform. They don't really need to develop a new set of API.

What's my experience with pricing, setup cost, and licensing?

The solution makes users pay integration fees.

You need to pay extra to get proper analytics. It's a separate fee.

What other advice do I have?

MuleSoft has both ESB as well as the API management platform. 

We are implementors.

We are one major version behind. We are not using the latest version of the solution.

We deploy on-prem and we also have deployment on our own AWS OSSIE code infrastructure.

It might be cheaper for someone to implement MuleSoft on-prem rather than on the cloud. With the on-prem version, we can deploy as many applications as we want on the on-prem version, provided the infrastructure is able to support it. However, for cloud-based deployments, they end up charging more.

I'd rate the solution at a nine out of ten.

Which deployment model are you using for this solution?

On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
AS
Enterprise Integration Consultant at a computer software company with 1,001-5,000 employees
Consultant
Top 20
Great for any company wanting a complete digital transformation

Pros and Cons

  • "One of the more valuable features is the stability of the platform."
  • "Not many stand-out features."

What is our primary use case?

My primary use case for the solution is as an API gateway. I am an enterprise integration consultant and I implement it for customers.

What is most valuable?

I would say one of the more valuable features is the stability of the platform. The API gateways across the market end up exposing more or less the same functionality when it comes to the mediation exposure of the proxies. It was decent to work with it even though there weren't many stand out features. The user interface is consistent across all of the products. It's difficult to differentiate APG from IBM Connect or MuleSoft Anypoint platform. They have a rich user interface. 

What needs improvement?

I think while trying to evaluate the various products on the market, and what could be improved, I'm looking at the indications and analytics and the off-the-shelf dashboards that come with it. Those are things that really catch the eye. At the end of the day, it's the functionalities and the way they integrate with the multi-cloud platforms and other backends that are underpinning the hood. If I have to present an API solution to somebody and if I can show them what are the off-the-shelf dashboards that you get in the analytics profile, that becomes a major eye-catcher to take the discussion forward.

For how long have I used the solution?

I've been using the solution for a year or so. 

What do I think about the stability of the solution?

Stability is very good. 

What do I think about the scalability of the solution?

I would think scalability depends on whether you're doing it on premises or on the cloud. I don't have experience with that but I think, for example, since Kong is more into clustering and the like, so scalability in Kong should be more straightforward because it's more evenly distributed. 

How are customer service and technical support?

I haven't contacted technical support but I have been in touch with some of its engineers and they were a pleasure to deal with. They're good engineers and they are very helpful.

How was the initial setup?

In terms of initial setup, of course WSO2 with Kong is more simple than this.

What other advice do I have?

The advice I would give is that this is a platform that's meant for a complete digital transformation of an organization. If you want to realize the entire capacity or the entire power of the platform with the capability APIs and the system APIs, you know you've got to use the API-led connectivity. And here I think lies the true power of the platform; that instead of using it just as an API gateway, you can take it further and I think that is the real value that market peers are not able to offer. It's a standout feature of the API platform and MuleSoft.

I make proposals and whether the customer chooses it or not is up to them. I usually look at  different products, and then we try and see what fits the customer best. It's not black or white. If there is a need for an entire landscape of low APIs and not just proxies, I think MuleSoft is a good way to go.

I would rate this product an eight out of 10. 

Which deployment model are you using for this solution?

Hybrid Cloud
Disclosure: My company has a business relationship with this vendor other than being a customer: Implementer
SunilDsouza
Vice President at Bosch Automotive Electronics India Pvt. Ltd.
Real User
Top 10
Excellent technical support with good scalability and stability

Pros and Cons

  • "Whenever there was an issue, the support was excellent."
  • "The pricing is quite expensive. It should be adjusted to make it more affordable for users."

What is our primary use case?

The primary use case is for partners to exchange data and information with our company. It can be board members, as well as customers that can connect with us in order to exchange data. 

What is most valuable?

Overall the platform is good. The stability of the platform is very good. The entire solution has worked well for us. 

Whenever there was an issue, the support was excellent. 

What needs improvement?

I work with the solution more from a strategy perspective. I don't get into the day to day of how it is run and things like that so I'm not sure if I'd be able to get into features or what may be missing.

The pricing is quite expensive. It should be adjusted to make it more affordable for users.

When they come up with a completely new version of the solution and there is no direct upgrade for the customer from the older version to the new version there's a lot of work to be done. Whatever time and money you have invested cannot be directly used in the new platform.

When they come up with a new version release or a new platform the customers, existing requirements, etc. should be transferred over easier. Migration every time there is a new version is difficult. It's something that they could fix.

For how long have I used the solution?

I've been using the solution for the last three years.

What do I think about the stability of the solution?

The stability of the solution is excellent.

What do I think about the scalability of the solution?

The scalability of the solution is very good.

How are customer service and technical support?

We've found technical support to be excellent. We've been very satisfied with the level of service that the solution provides.

How was the initial setup?

The initial setup isn't complex, although when you are installing the solution you need a moderate amount of competency.

Deployment took about six months.

What's my experience with pricing, setup cost, and licensing?

The licensing costs for the solution are quite high.

What other advice do I have?

I'd rate the solution nine out of ten.

Mainly the pricing is the big down-side of the solution. 

I'd advise others to ensure that they need to have the right partner who understands the system before they get into the implementation process.

Which deployment model are you using for this solution?

Public Cloud

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Disclosure: I am a real user, and this review is based on my own experience and opinions.
CO
Executive Director Finance & Strategy at a consultancy with 51-200 employees
Real User
Top 5Leaderboard
Stable, flexible, and scalable

Pros and Cons

  • "The scalability is good. It's passable."
  • "The pricing is a bit expensive."

What is our primary use case?

The solution is basically a SOAP API and REST API.

What is most valuable?

The solution is very flexible. It's a great aspect of the solution for us.

The solution is stable.

The scalability is good. It's passable. 

What needs improvement?

The pricing is a bit expensive. It would be better if they offered more price-conscious licensing.

For how long have I used the solution?

I've been using the solution for a couple of years at this point. It's been a while now. I have some experience with it.

What do I think about the stability of the solution?

The solution is stable. It's good. There are no bugs or glitches and it does not crash or freeze. The performance has been good. 

What do I think about the scalability of the solution?

The solution can scale if a company needs to expand it. It's pretty good. 

We have 30 people using the solution right now. 

How are customer service and technical support?

We've contacted technical support and they are very helpful and responsive. They're good. I'm satisfied with the level of service provided to customers. 

Which solution did I use previously and why did I switch?

We also use Tencent which is just more compatible with enterprise architecture.

How was the initial setup?

I'm not overly familiar with the initial setup, however, my understanding is that it is an average level of difficulty. It's not overly simple or complex. 

We have four people that can handle maintenance duties. They are managers and admins. 

What about the implementation team?

We used a consultant to assist us in the implementation process. 

What's my experience with pricing, setup cost, and licensing?

The pricing could be better.

We pay a licensing fee on a monthly basis. 

What other advice do I have?

I'd rate the solution at an eight out of ten. It's good. I've enjoyed using it.

I would recommend the solution to others. It's a good platform. 

Which deployment model are you using for this solution?

Public Cloud
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
Product Categories
API Management
Buyer's Guide
Download our free Mulesoft Anypoint API Manager Report and get advice and tips from experienced pros sharing their opinions.