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

Apigee Alternatives and Competitors

Get our free report covering Microsoft, MuleSoft, Amazon, and other competitors of Apigee. Updated: September 2021.
542,267 professionals have used our research since 2012.

Read reviews of Apigee alternatives and competitors

Rully Feranata
Enterprise Architect at PT Bank Mandiri (Persero) Tbk.
Real User
Top 5Leaderboard
We developed several services in the cloud using a sandbox environment for our last hackathon

Pros and Cons

  • "Within the new version, webMethods API Gateway gives us an end-to-end lifecycle from the creation of the API up into the development, deployment, and promotion into production/live. The current end-to-end lifecycle of the API gives us enough authority and governance of the API. We know what are currently live services, what is in the testing stage of development, and what version that has been commissioned. So, the full life cycle itself gives us full authority and governance of the API."
  • "With performance, there is room for improvement in regards to if we would like to put another extra layer of security on it, such as SSL. This is affecting their performance quite significantly. They need to improve the process of managing the SSL and other things inside their solutions, so there will not be quite such a significant impact to the performance."

What is our primary use case?

We have an open banking initiative in Indonesia. We are mandated by a regulator's bank in Indonesia to open up our services to other institutions, not only banks, but also financial technology (FinTech) companies and startups as well as eCommerce or other industries.
Thereby, they can consume banking services through an API, such as our funds transfers, mobile banking services, or a bill payment, like electricity, water bills, college, and so on, through an API to their applications. It is not obligatory that you need to download our mobile banking in order to do these transactions, but you can do the transaction using other applications, such as the FinTech or eCommerce application that the customer currently has. Those use cases, for the open banking readiness for Indonesia, utilize webMethods API Gateway and standardized services of API for fund transfer, debit credit transfer, bill payments, and opening up a savings account using online applications. Those are pretty much the use cases for webMethods API Gateway in order for us to connect it with FinTech startups, eCommerce, and other institutions who would like to consume banking transactions through Mandiri.

Since we are a very highly regulated industry, which is a bank in Indonesia, we are not allowed to host any financial transaction outside of the Indonesian region. So, the solution must be deployed on-premise inside of our data center.

Are you using multiple products from this vendor?

We are using multiple products to build the end state of our service-oriented architecture (SOA). This is all orchestrated as a big building house. Those SOAs have many capabilities inside of them on the integration side, such as webMethods Integration Server. (Read my webMethods Integration Server review here.) There is also webMethods API Gateway and Software AG Apama. Those modules inside of Software AG complement the building blocks of SOA.

We also use it to complement other products in the markets outside Software AG, such as Kafka as well as all event processing and streaming. This is in combination with the capabilities (and beyond) of what Software AG stacks can do.

I find the native integrations between Software AG products to be very useful from a plain vanilla standpoint. Though, when we implement native integrations, there needs to be slight customizations to fit them into our core legacy system, and that needs to be integrated with other systems. For plain vanilla capabilities, it is sufficient enough.

The native integrations between Software AG products also have good performance in terms of transactions per second (TPS). These are acceptable in terms of the volume and speediness of a transaction that we can produce as well as being combined with the efficiency of using the hardware, memory, and CPUs.

If you combine the commodity hardware and performance as well as the plain vanilla capabilities of internal products that Software AG has, then there is a good price per value.

It gives you a one-stop service for your integrations area. You can really rely on one vendor, then you don't have to worry about sustainability or support. This is all guaranteed by Software AG as a single stop service from them. Whereas, when you need to combine other vendors, then you need to monitor each of their solutions, sustainability, product roadmaps, etc. Then, this becomes your technology liabilities, which is something that we consider. From the integration, we are selecting a good strategic partnership with one vendor in order to maximize our productivity. Thus, we don't have to worry how we can monitor each respective vendor if we do a best of breed combination of many vendors, just to do an integration.

By selecting Software AG and using multiple products, this saved us about 72 percent, which has definitely given us more agility.

Because we were already accustomed with webMethods Integration Server way before the webMethods API Gateway, they were almost the same. We just converted our knowledge from the prior WSDL into RESTful JSON standard messages. Therefore, the learning curve was very smooth because the environment that the developers use was still the same: My webMethods Console. It uses the IDEs coming from that, saving us a lot of time with the learning curve on new technologies.

How has it helped my organization?

Within the new version, webMethods API Gateway gives us an end-to-end lifecycle from the creation of the API up into the development, deployment, and promotion into production/live. The current end-to-end lifecycle of the API gives us enough authority and governance of the API. We know what are currently live services, what is in the testing stage of development, and what version that has been commissioned. So, the full life cycle itself gives us full authority and governance of the API.

You can carefully select what services can be consumed by the outside and what services can only be consumed internally. Also, you can see what the fallback scenario is, if some services are customized and what is the impact analysis, e.g., what is the impact to other services that depends on certain services that we are currently automizing. These are very critical capabilities for API implementation in any organization. You do need to have good API governance for it, not only tools, but also all the procedurals. You will need all the standard operating procedures for starting a development of API up to deployment into production.

webMethods API Gateway provides an engagement platform for managing hackathons. Our last hackathon was in 2019. We developed several services in the cloud using a sandbox environment, so it does not connect with our real life production environment. We created some accumulated transaction behavior, so hackathon developers could connect it with our box services within the sandbox environments. It does provide good freedom to host competition in an isolated environment.

At Mandiri, we divided webMethods API Gateway into two layers, the external API gateway and the internal API gateway. The external API gateway is for Mandiri channels and our core partner channel for feedback, eCommerce, and other institutions. With their channel, they like to connect and consume services. webMethods API Gateway gives you a sense of security and quite adequate minimum security to secure services, e.g., DDoS attacks, man-in-the-middle attacks, and queries for SQL injection. These are already built inside of webMethods API Gateway. 

It has a good role definition and scope for its services. Expected channels can only access what type of services, and we can define those as per our contract with prospective partners. So, it boils down to the architecture: How do you like to architect the integration and partnering with other institutions? It depends on that. However, the system itself gives you that flexibility.

What is most valuable?

webMethods API Gateway gives us a set of rules and good security for securing outside work to connect with our services. It has good minimum security measurements built-in. However, webMethods API Gateway itself has very minimum API governance. You need to have a central site in place to have full-fledged governance, which is one of their modules.

The solution provides a fully customizable portal that has built-in testing and collaboration capabilities. Because it is similar with other well-known products in the market, the process doesn't have specific requirements. We do have a good adoption rate. We only have two weeks of learning and customizing the behavior to developers. By the third week, every developer can actually develop by themselves.

What needs improvement?

Previously, we had some difficulties with end-to-end lifecycle management of APIs because the product was not yet mature enough. Two years ago, it was not yet mature in terms of the capabilities, which were still separated and not yet consolidated. There were several modules of webMethods API Gateway which needed to be consolidated into one webMethods API Gateway. Previously, they had two separate modules for API management as well as others. 

One of the improvements that need to be added into future releases is the ability to support other third-party monitoring tools. I know that they already support Jenkins, but in Mandiri. We use Bamboo for the deployment as well as part of Jenkins. We also install other monitoring tools, such as AppDynamics, for collecting information on performance and the problems of API Gateway hosting services. 

With performance, there is room for improvement in regards to if we would like to put another extra layer of security on it, such as SSL. This is affecting their performance quite significantly. They need to improve the process of managing the SSL and other things inside their solutions, so there will not be quite such a significant impact to the performance.

With their API-Portal, you need to have flexibility when changing the layout and teams, giving more flexibility to rearrange and do some type of UX/UI that fits into your organization. The API-Portal that comes from Software AG has some of those limitations, with only certain parts that can be fully customized.

For how long have I used the solution?

We have used it for almost three years, since 2017.

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

How do you get money from selling or offering your financial services to the other partners or institutions? It comes down to monetization. How do you monitor usage of certain particular protection or usage of services? I do see a lack of capabilities inside of the monetization area for them. They have a cloud infrastructure that is pay per use type of a thing. If you already use 1,000 transactions per se, then you can be charged and billed. I see room for improvement there for their side on that particular capability of the monetization.

Which other solutions did I evaluate?

We have evaluated other solutions, such as Apigee and MuleSoft, back in 2016. but since we already have Enterprise Service Bus that is using the integration server, which is collecting and managing all the integration services inside, we wanted to see the end-to-end picture of the service itself. It was very logical that you need to have end-to-end monitoring and trend deployment from the service deployment, up into exposing the external world using webMethods API Gateway. We see those advantages from using webMethods compared with other solutions, such as Apigee or MuleSoft, because of the continuation of the architecture. We would also like to expand those into our separating stacks.

What other advice do I have?

In every implementation of webMethods API Gateway, I strongly suggest that you need good API governance. webMethods has their API governance all built inside of your license. It is a continuation between the services using the webMethods Integration Server and webMethods API Gateway, exposing those services into the outside world. You need to have good governance for that.

I would rate this solution an eight (out of 10).

Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Igmar Rautenbach
Head: B2B Solutions at Trustlink (Pty) Ltd
Real User
Top 5Leaderboard
Good documentation, strong security functionality and offers great flexibility

Pros and Cons

  • "There's drag and drop functionality so that you do not need to have a senior expert developer to make use of the tool. You can get more of your staff trained up to be able to use it as it's not overly technical."
  • "The installation process is a bit complex and it could be a lot simpler."

What is our primary use case?

We make use of Axway's API gateway API management tool.

Its integration with middle wear is similar to ESB. We provide integrations as we are a swift services bureau. We've got customers that are banks and in some use cases. We integrate these banks with their own back office and we tend to provide integration for that. 

We also make use of the solution to build a marketplace of financial services, which is basically our own solution. 

For other customers, we do integration of the various source systems, back-office systems, legacy systems, etc. We also do file transformation where we take messages for customers in their environments and translate it to industry formats. 

What is most valuable?

There's drag and drop functionality so that you do not need to have a senior expert developer to make use of the tool. You can get more of your staff trained up to be able to use it as it's not overly technical. 

It provides very strong security functionality to protect information in an easier way. 

It's more of a benchmark for financial services. You can better protect the information and customer information as it's got a very strong focus on security. 

The flexibility is very good. You can do on-premise and you can do cloud. That's really a strong factor in our market as many large customers in our market still want to have an on-premise solution due to the fact that they want to maintain control over their data.

Previously, the solution did not have a subscription as an option, however, now it also has a subscription model, which is great.

The documentation is fairly good and readily available.

What needs improvement?

The pricing could be more competitive. 

The installation process is a bit complex and it could be a lot simpler.

Currently, there's a strong focus on microservices, which is already there and already available. They're already able to deploy in dockerized containers. In that sense, there's nothing that I can actually see that is missing from my side.

For how long have I used the solution?

We've been dealing with the solution for the last three years.

What do I think about the stability of the solution?

The product has got strong security features, from a stability point of view. There's a large footprint in the financial services sector, where you deal with daily transactions in the millions. It has a very strong focus on stability, and our experience as well has been that, as we also use it in a payments environment, it's been proven to be quite stable. 

What do I think about the scalability of the solution?

We have probably eight people who make use of the solution in our organization.

It is a solution that is strong enough to be used by enterprise-level customers. That is the target market. However, it provides such strong features, that it is used in our environment by FinTech startups, and also by other mid-range customers that are not really at the enterprise level. It solves their issue of integration and to decouple their back-office systems so that they can develop one in a specific area, and make their system changes. It's a very versatile product; many organizations can benefit from it.

The solution is scalable. That is a benefit of the platform in itself. It provides you with scalability so that you don't have to develop all your back-office systems. The product itself is scalable in the sense that you can spin up additional environments very quickly. 

Its price scalability is also very good as you don't necessarily pay for extra usage. You pay a fixed subscription. In terms of dealing with high volumes, it is also scalable in the sense that you can just add processing capacity where you need to.

How are customer service and technical support?

We actually provide support to customers. We provide remote support as well as on-premise support. From a support point of view, we are happy, as it provides a lot of analytics. With the analytics, you can very quickly drill through transactions and see where there are issues. 

We don't foresee any difficulty with the support of the solution, and we are support providers. It's always important to have someone, to have a vendor that provides you with at least level three support so that your operational teams can be at their best productivity-wise.

The support desk is very good. I deal with them regularly. You raise a ticket as normal and they will then guide you through to a resolution.

How was the initial setup?

The initial setup is a bit complex. 

It is now Dockerized containers. That makes the whole process of installation and upgrades much more simplified. Their version 7.7, the last version, means that from here on there will not be a big change. You have to completely build an environment, however, after that, you will only patch it. 

It's software that has complexity. It's a middleware system that is set up in various environments, however, it needs to align with the corporate policies on security and DMZ. You have to design it and then you have to build it. You probably will be okay during implementation if you make use of certified technicians to assist you with building the solution.

The positive with the solution is that, once you are operational, you should be able to maintain the solution with a very small team. There are instances where there's a footprint of multiple installations - more than 20 for a global organization. Yet, they've got just one core team that actually maintains all of those installations. That illustrates the sort of scalability it has when it comes to supporting a large footprint.

If our clients need it, we can provide maintenance for them. We can do tasks such as patching, updates, etc. Customers, of course, can also handle maintenance themselves.

What about the implementation team?

It's best to get a professional technician to handle the installation as you want to make sure that it's configured correctly to get the best use out of it. Once you are operational, you can really make use of your own skills to maintain it.

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

The pricing is fair. They're still investing in development and provide much-needed functionality and with the assurance that it will not leak your data or provide you with gaps in your risk. From a pricing point of view, I don't think it's on the high side. I would say it's a mid-market price and there's flexibility in their pricing options. 

Which other solutions did I evaluate?

We evaluated a number of API solutions, including WSO2, Apigee, and IBM and in the typical use cases where we deal with enterprise and financial customers. We found that some of the solutions either did not have good enough documentation, good enough support or maybe a lack of on-premise functionality. Pricing on some options was also an issue. We made the decision to use Axway after looking at it and others across these and a variety of other parameters.

For example, in the case of WSO2, our Financial Services client made use of it, however, for us, it was very difficult to understand and to problem solve that solution, and documentation played a role as it wasn't the best. 

We're also partners with IBM. The platform for us, the number one issue, is its price. On top of that, it's really more for the adoption in a mid-market space. 

We looked at Apigee and others where it's more power-orientated and that doesn't solve the problem that financial services, healthcare, and other vendors had as they wanted to have better security and have the data in on-premise.

What we found, in the European market at least, was that Axway has very strong links to financial services, transport logistics, healthcare, and banks. These are its primary industries. For us, it was important that the solution we chose had a strong knowledge base across those industries, and not only focused on a specific industry.

Some of the other vendors have got a very wide focus. For us it was easier to find agreements when looking at Axway's Roadmap. It was really important to see, that the business is focused around the solution and they execute on their Roadmap and develop out the solution continuously.

What other advice do I have?

We're largely a customer, although we are consultants and refer Axway often.

While we use the solution's cloud deployment model, we also engage with the on-premises version as well.

I'd advise other companies considering a solution like this to first go and determine their strategy around APIs in their business. That's really important. There needs to be a plan around how a company is going to manage APIs. A business needs to ask itself: What is the digital transformation strategy? They need to approach this as a strategic investment and already have some strategy behind it. 

It really is core to your digital transformation, to your ability to unlock new revenue channels for a lot of businesses or to reduce cost in your back office systems. Therefore, there must be some sort of strategic benefit that you see before you actually evaluate API platforms. 

Once you've got a strategy, you're sure that this matches your strategy. You probably need to also look at the first use cases that you want to do. You have to find a use case that shows a business benefit to deploying. It doesn't help you implement the solution just so that lots of people can use it for different things. You must find some anchor or use case that you will be able to sell. Then it will become a benefit to your internal business.

From there on it's really, really important to identify integration partners that are certified that can actually assist you from a business point of view, to deploy quickly. The quicker you get the benefit, the quicker you get the new revenue from whatever you want it to do. After that, it's crucial to internalize the knowledge around the solution. It is important to do good skills transfer so that you can have confidence in using the solution long-term.

Overall, I would rate the solution nine out of ten.

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?

Amazon Web Services (AWS)
Disclosure: I am a real user, and this review is based on my own experience and opinions.
VV
Consulting architect at a tech services company with 501-1,000 employees
Real User
Stable and easy to set up but might be too costly for small businesses

Pros and Cons

  • "API Connect's most valuable feature is its ability to act as a gateway. It's very easy to configure security and everything else in it. You don't have to kill yourself implementing custom configurations."
  • "One thing about API Connect that could be improved is the security schemes. There are so many security schemes, and from a product perspective, IBM could improve the user experience of the configuration security scheme."

What is our primary use case?

My clients mainly use API Connect as an API gateway. A lot of the backend services need to be exposed to other parties, mobile devices, interfaces, etc. 

What is most valuable?

API Connect's most valuable feature is its ability to act as a gateway. It's very easy to configure security and everything else in it. You don't have to kill yourself implementing custom configurations. Sometimes the customer wants to incorporate their identity provider, and API Connect handles that without any problems. 

What needs improvement?

One thing about API Connect that could be improved is the security schemes. There are so many security schemes, and from a product perspective, IBM could improve the user experience of the configuration security scheme. It does what it is supposed to do, but it could be easier to configure. The junior developers sometimes find it a bit confusing to configure even though they understand the concept.

And another thing is that I don't know the security policies that we have. For instance, we have a service account, which is needed to connect to some other services. So in those cases, I find it a bit hard to tweak things in the API gateway. And one could argue that it is not the right thing to do with the API gateway. It has a different place to be, which could be why they haven't put it there. But sometimes, you have to tweak around that, and I find it a little bit hard to do that. So if they could accommodate that in there, it would be better for some people.

For how long have I used the solution?

I've been using it for the last four years on and off. The last time I deployed it was a few months ago.

What do I think about the stability of the solution?

API Connect is reliable.

What do I think about the scalability of the solution?

API Connect is scalable, but I've found that everything is more stable if you reset the server every 40 or 45 days. Once, we had an incident in which we were unsure about what happened, but it crashed after 60 days. We didn't know the reason. It could've been a mistake in the product implementation. We don't know what happened, but this particular incident occurred two times. After that, we began restarting it every 45 days. So that's the resilience part, but the scalability part works without a problem.
Another thing is that we don't know all of the use cases that we have worked on before, so we didn't go for automatic scaling of the API gateway. That's done in the backend services. So I'll be honest to say that we haven't explored the auto-scalability of API Connect much. Instead, we put that on full throttle. This can cause a bottleneck if we play around with it, so we didn't take many risks. We put that on full throttle and did the tweaking in the backend services. That's how we did it in the past.

How are customer service and support?

I've interacted with IBM support many times. They're good. They get back to you within 12 or 14 hours after you initiate a ticket. IBM support will get on a call with you if needed and guide you. It's no problem. They provide the same level of support to everyone. 

How was the initial setup?

Setting up API Connect is a straightforward process. Maybe it seems more manageable because I've been taking baby steps rolling it out for the last few years. So when we talk about the latest version, it's not a headache if you follow the documentation. Even for an operations person, it's a piece of cake. 

It takes a minimal amount of time to deploy as a product. Including the processes for the organization, installing the product could take half a day. And when we ask the Ops team to do it, it usually takes half a day for them to do it. They have to document the IP and keep a log of what they're doing. 

API Connect itself does not require any maintenance. But when our teams write the business logic into it, that usually requires some support and maintenance. So a team of two people looks after the whole setup. And they work in shifts. Usually, it works on an onshore-offshore model. So one person from the onshore team will be supporting it for some time, and when he goes off, the other person comes up. 

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

API Connect's license cost could be a little lower. But, unfortunately, there aren't many open-source API gateways. Ideally, some new developers could come up with a minimum-functionality open-source solution. When I look for open-source resources that work with API C or Apigee, I find very few that can do that. It's not available or very popular in the open-source community. I've only worked with large companies that are capable of affording these licenses.  A better option for smaller companies might be to have two or three developers build a custom API gateway. That might be more affordable for them.

What other advice do I have?

I rate API Connect seven out of 10. I would recommend it to customers if they have the money to pay for it, but it depends on the ecosystem. So, as a consultant, I would recommend API Connect if the customer already has an IBM license. Big companies generally have IBM middleware running somewhere, so they might have a license for these things. In cases like this, we would usually recommend API Connect for their purposes rather than spending more money on a different product. And if a client is building something entirely new and has to get a new license, we'll compare the options, including Apigee, MuleSoft, API C, or a custom solution. 

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
GD
Group Manager, Solution & Technical Architect at a tech services company with 10,001+ employees
Consultant
Top 20
Easy to configure, simple to use, but might not be suited for all sized companies

Pros and Cons

  • "I have found this solution to be easy to configure, simple to use, and flexible."
  • "If I compare this solution to others I have used in other phases of my life, having APIM being an Azure resource, it is easy to configure and deploy. However, this conversely reduced the flexibility. The difficulty is how do we configure it in a manner that a larger enterprise would probably want it to be. This creates a bit more complexity, working around the constraints of the resource itself. If comparing it to other solutions, it is more of a legacy design with an older approach. The various level components are still around resembling an on-premise type of design similar to other solutions, such as Apigee or Mulesoft. They are still predominantly carrying some legacy design. Which might be suited for organizations where they have a more complex network layout. APIM is easy to deploy, but on the other side of that, it is constrained to how Azure has designed it to be."

What is our primary use case?

We use this solution because when there is a technical requirement sometimes there are technical constraints that need to be overcome, and that is best resolved through the API component. My organization predominately uses Microsoft solutions and this is why we are using this particular solution.

What is most valuable?

I have found this solution to be easy to configure, simple to use, and flexible.

What needs improvement?

If I compare this solution to others I have used in other phases of my life, having APIM being an Azure resource, it is easy to configure and deploy. However, this conversely reduced the flexibility. The difficulty is how do we configure it in a manner that a larger enterprise would probably want it to be. This creates a bit more complexity, working around the constraints of the resource itself. If comparing it to other solutions, it is more of a legacy design with an older approach. The various level components are still around resembling an on-premise type of design similar to other solutions, such as Apigee or Mulesoft. They are still predominantly carrying some legacy design. Which might be suited for organizations where they have a more complex network layout. APIM is easy to deploy, but on the other side of that, it is constrained to how Azure has designed it to be.

In an upcoming release, if not already added through an update, I think dynamic provisioning of the resource would be useful. Many times these API platforms, including others, such as Apigee, are still predominantly revolving around developers. The onboarding and the API life cycle are still revolving around humans. In this context, I would not suggest DevOps, but at least automation of common pipelines. If the platform can better support this in the workflow to provision and commission an API that would be beneficial as we work towards a more automated deployment concept. Even though there are templates, graphics, and API management commands right now, you are still in a way programmed deeply, customizing that workflow, as opposed to it being part of the platform itself.

For how long have I used the solution?

I have been using Azure solutions for approximately four years.

What do I think about the stability of the solution?

The solution is stable.

What do I think about the scalability of the solution?

The solution is scalable because it is a cloud service offering.

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

I have previously used Apigee and Mulesoft.

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

Since this is a cloud-based solution you have to abide by those financial limits, this creates some different challenges compared to other solutions.

What other advice do I have?

My advice to those wanting to implement this solution is in all technology areas, each solution is use case-specific. If you are already working on the pure Azure Stack, then APIM is something that I would suggest. Unless you have a very complicated API development use case I would not try to deploy, for example, Mulesoft or Apigee on Azure. Assuming you are working on a full Azure Stack solution. 

Since it is use case-specific, rather than trying to build out. I would rather use the other repertoire of Azure to do the API development, as opposed to trying to deploy other solutions under the platform and develop from there.

My philosophy is always, use what is available, rather than trying to reinvent the wheel. Mulesoft may be powerful, but it is putting the cart on top of the wheel and try to build something on the cart. It is not a native approach.

I rate Microsoft Azure API Management a seven out of ten.

Which deployment model are you using for this solution?

Public Cloud
Disclosure: My company has a business relationship with this vendor other than being a customer: Partner
Flag as inappropriate
Alfredo Silva
Experience Design Lead and Strategist at a consumer goods company with 51-200 employees
Real User
Top 5Leaderboard
Many API protections against attacks, reliable, and good technical support

Pros and Cons

  • "When I have used technical support they helped me a lot. Sometimes they took a long time to respond because we had very complex issues that we asked them for help with, but I think it is a very good service."
  • "The Policy Manager tool that is used to manage the solution is very heavy to use because it is based in Java. Sometimes it takes a long time to load. There could be some improvements to it. If they could make Policy Manager on a web page that would be a good alternative."

What is our primary use case?

Our clients use the solution for a secured layer to protect their API. Most of them have two kinds of API, the frontend, and backend.

What is most valuable?

There are many beneficial features in this solution that protect against attacks, such as SQL, injection, and the internet.

What needs improvement?

The Policy Manager tool that is used to manage the solution is very heavy to use because it is based in Java. Sometimes it takes a long time to load. There could be some improvements to it. If they could make Policy Manager on a web page that would be a good alternative.

For how long have I used the solution?

I have been using the solution for approximately three years.

What do I think about the stability of the solution?

I have found the stability very good.

How are customer service and technical support?

When I have used technical support they helped me a lot. Sometimes they took a long time to respond because we had very complex issues that we asked them for help with, but I think it is a very good service.

How was the initial setup?

The initial setup was very easy and straightforward. However, the first and second time we did it was a bit complex because we were not used to the installation.

What about the implementation team?

We have done the implementation and the time it takes depends on the client's use case. You can do the installation and have some APIs working to generate some values for the clients in approximately 30 days.

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

This solution is a bit more expensive than competitors.

Which other solutions did I evaluate?

My clients evaluate others solutions before they chose this one, such as AWS, and Apigee from Google. The most common option that they evaluated was Apigee because of the price.

The main difference was AWS and Apigee to this solution is they have a lower price but they do not have all the features that this solution has. It depends on the client, they have to decide between what features they want to implement. If there are not many features to implement they can go with Apigee or AWS, but if there are more complex implementations they try to go with Layer7.

What other advice do I have?

I would recommend this solution to others. I really like the solution.

I rate Layer7 API Management a nine out of ten.

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?

Amazon Web Services (AWS)
Disclosure: My company has a business relationship with this vendor other than being a customer: Partner
Flag as inappropriate
Get our free report covering Microsoft, MuleSoft, Amazon, and other competitors of Apigee. Updated: September 2021.
542,267 professionals have used our research since 2012.