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

webMethods API Gateway OverviewUNIXBusinessApplication

webMethods API Gateway is the #13 ranked solution in our list of top API Management tools. It is most often compared to webMethods.io Integration: webMethods API Gateway vs webMethods.io Integration

What is webMethods API Gateway?

Once your APIs are “out there,” hackers have a “way in” to your business. Lock that door! Protect your data, applications—even your company’s reputation—with robust API runtime security. The right API gateway will keep out wrong-doers and welcome only authorized consumers.

With cybercrime costs surging to $2 trillion by 2019, look for the most impermeable API gateway you can find. You’ll need basic security features, like authentication, authorization, digital encryption and digital signatures. You’ll get that with Software AG’s end-to-end API management solution—and another lock on top.

Our webMethods API Gateway uses reverse invoke, or inside-out, service invocations. This protective technique reduces the need to open holes in your firewall. It’s one more way we help you lock down your APIs—and protect your business from malicious attacks.

webMethods API Gateway Buyer's Guide

Download the webMethods API Gateway Buyer's Guide including reviews and more. Updated: September 2021

webMethods API Gateway Video

Pricing Advice

What users are saying about webMethods API Gateway pricing:
  • "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."
  • "This is not a cheap solution but, compared to other products such as those offered by IBM, the pricing is similar."

webMethods API Gateway 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
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.
Dries Vanmarcke
Technical Architect at Colruyt
Real User
Top 5Leaderboard
Secure, good monitoring capabilities, and the automation gives us a competitive advantage

Pros and Cons

  • "This solution has given us a competitive advantage because we have better automation and insight."
  • "With respect to the API gateway, the runtime component, the stability after a new release is something that can be improved."

What is our primary use case?

This solution is primarily used for protecting our APIs and web services. All of our APIs are exposed to the outside world, so our internal network is protected by the API gateway. Our landscape inside the company is also divided into different domains and if you go from one domain to another domain, we also want the APIs to be protected.

We have two servers with an API gateway and a load balancer in front of it.

We also use this solution for monitoring, to know how many transactions we have had and who is using our API. These are the runtime capabilities.

Another thing we use this product for is governance, to govern the lifecycle of our API services. It will tell us the state of the service, who is responsible for it, what deliverables belong to that stage, and we also have some quality checkpoints inside the lifecycle.

How has it helped my organization?

With respect to the end-to-end lifecycle management of APIs, this product is very good, feature-wise. We have the ability to govern the end-to-end lifecycle; in the different states, we can do the necessary customization and add our own flavor. This helps us very well in maintaining it.

The API governance capabilities for enforcing standards and security policies are quite good. However, it is a new product that started a few years ago, and you can sometimes tell that it is new and still evolving. For example, there are some bugs and problems that are still being fixed as it is further developed. They are evolving the features and we are happy with the product, but there can be more issues that arise as things change.

These quality checkpoints allow us to have a central team that reviews the deliverables of the service. In the Design phase, for instance, we will review the REST API interface to see if it matches our standards.

This solution has enabled us to create new channels for growth because we can quickly introduce new APIs. Sometimes, you need to quickly set up a marketing campaign with an application that needs to happen fast. The API gateway allows us to introduce APIs that are still good and protected but in a fast way.

We have a good overview of all of our APIs, including who is providing them and who consuming them, which allows us to better work together to resolve issues before they emerge. For example, if there are changes made, we have a better view of the impact and the team can start discussing it. Also, if we are deprecating services and removing them, we know who is using these APIs and they can be contacted in advance.

Another important point is that when a new application wants to use an API, it can provide the necessary information such as the number of transactions. With this knowledge, the provider can adapt accordingly and it will be possible to add it.

Using the product has provided us with a structured API management program. Because we have governance and knowledge about all of the APIs, we have a better overview. Knowing who is using an API, or who is going to use it, means that it is easier to introduce new things.

This solution has given us a competitive advantage because we have better automation and insight. Without it, a lot of automation would not be possible, and doing it manually would take more time.

More generally, this API gateway has improved the way our organization functions because it allows us to enable more partner integrations. Until now, most of our business-to-business integrations were going over EDI. With API instead, it will allow us to onboard other partners. The reason for this is that EDI is a very heavy format, which is very expensive. As a retail company, EDI is affordable when you have a large vendor. But sometimes we have smaller vendors, and if we force them to use EDI, it will sometimes block the ability to sell products to us because they can't afford the complete functionality of sending invoices or receiving orders.

What we are now doing with API management is to make the order and invoicing systems available via API. These smaller vendors can then use these APIs to send an invoice or to receive an order.

What is most valuable?

The two most important features are the lifecycle and the protection of your APIs.

On the topic of protecting your APIs, every API management solution has that, which is the core business. Without it, you don't have an API gateway and it's the basic setup that every API management solution needs. Of course, protecting your APIs is very important.

With respect to the lifecycle, it is helpful because, in our business, we find it important to have an overview of all of our APIs and to guide our different roles, including architects and solution developers, in the necessary work for delivering a web service. Depending on the type of service, we also want to govern the quality. We don't do it for all APIs but for some categories, we find it very important that the quality is at a high level. This means that we want to govern that and to review it.

In these aspects, this solution helps us.

What needs improvement?

In relation to the lifecycle features, the user interface and the performance can be improved. It is not the quickest application and the user interface is not most up to date. It's a tool that has existed for quite some time, and there haven't been a lot of improvements.

With respect to the API gateway, the runtime component, the stability after a new release is something that can be improved.

For how long have I used the solution?

I have been working with the webMethods API Gateway for approximately four years.

What do I think about the stability of the solution?

Once the system is set up and configured properly, it's stable. We don't have outages and it runs very well.

What do I think about the scalability of the solution?

There are two ways to scale this product, and both of them are easy to do. The first is to add another server to your cluster, and the second way is to add more CPU power.

How are customer service and technical support?

I would rate the technical support medium-high. It is comparable with other companies; not worse, but not especially better.

In general, I am happy with the support but my complaints are about the timing. Specifically, if your issue can be handled by the first line then you get feedback quickly. However, if the issue is complex then it needs to go to R&D and it takes time. This is the same experience that I have with other companies.

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

We did not use another similar solution prior to this one.

How was the initial setup?

The installation and initial setup are complex. It is not possible to just keep clicking the Next button during the setup. You need to configure the system such that it works best for your environment. You should plan for deployment over three to six months, at least.

My advice is to involve a consultant from Software AG to help you with the setup. Of course, this is an on-premises situation. In the cloud, I don't know how easy or difficult it is.

What was our ROI?

We have seen ROI from this product and we are able to determine this because of our internal accounting. When a project starts, we always calculate what our benefits are with respect to the technology. Taking into account the number of web services and APIs that we have, we're pretty sure that considering the cost of governance, this solution is better than if we were not using one.

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

This is not a cheap solution but, compared to other products such as those offered by IBM, the pricing is similar.

Which other solutions did I evaluate?

We did evaluate other options including IBM API Connect and Apigee. Feature-wise, these products are comparable.

Given that we were already using webMethods, using the API gateway had some benefits. There is value in staying with a single vendor, with the advantage that it is easier to integrate with other products in the webMethods stack.

We did not consider using any open-source alternatives.

What other advice do I have?

This solution provides a fully customizable portal that has built-in testing capabilities, although we haven't implemented it yet. This is something that we are planning to do within the next couple of months.

My advice for anybody who is implementing this product is to involve consultants who are familiar with it because they can help you to best set it up. Also, think about the process and steps in your governance because this is a workflow and you want to be sure that it follows the procedures that you have in place.

Overall, I'm happy with the product.

I would rate this solution an eight out of ten.

Which deployment model are you using for this solution?

On-premises
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.
Flag as inappropriate
Learn what your peers think about webMethods API Gateway. Get advice and tips from experienced pros sharing their opinions. Updated: September 2021.
540,694 professionals have used our research since 2012.
Ram Kanumuri
Vice President - Digital Integration at Kellton Tech Solutions Limited
Real User
Top 5Leaderboard
Easy to set up with runtime metrics and offers good insights into the operations of the API

Pros and Cons

  • "The cloud version of the solution is very easy to set up."
  • "In terms of improvements, maybe on the API monetization side, having users able to create separate consumption plans and throttle all those consumption plans towards the run time could be better."

What is our primary use case?

The API Gateway and Portal go together. It's not one or the other. Essentially they're just leveraged for overall enterprise API management facilities, being able to go on the API development life cycle, being able to go on the API run time, API monetization, things like that. Usually, most organizations, most of our customers use APIs to supplement other architectures, typically microservices-based application architecture, and SaaS integration etc.

How has it helped my organization?

API Gateways and API Management in general first and foremost standardizes and democratizes the Integration problem across all IT domains. API Gateway specifically allows for centralizing all integration interfaces to a simple style and normalizes the patterns of security, access control, cross-domain compatibility across the enterprise. API Gateways also enable enterprise integration across various public cloud infrastructure and enable Hybrid nature of Enterprise IT.

What is most valuable?

On the API gateway, I would say the runtime metrics that the gateway collects are definitely useful.

The product provides a lot of insights into the operations of the API itself at runtime.

The cloud version of the solution is very easy to set up.

The stability has been good. The performance is strong.

The scalability is excellent overall.

We have found the technical support to be very helpful and responsive when we have questions.

What needs improvement?

In terms of improvements, maybe on the API monetization side, having users able to create separate API consumption plans and to be able to throttle API execution against those consumption plans at run time could be better. Those are abilities that might need some improvement.

The on-premises setup can get a little complex, needs to be more simplified.

For how long have I used the solution?

I've been dealing with the solution over the last three or so years at this point.

What do I think about the stability of the solution?

The stability and performance are excellent. 3G really comes strong on an enterprise-scale in terms of stability and performance. It doesn't crash or freeze. There are no bugs or glitches. We find it to be reliable.

What do I think about the scalability of the solution?

We have found that the solution scales quite well.

API management is all about internally leveraging the software development life cycle, across various domains. Typically, most customers, when they adopt API management, they are delivering it for their entire IT software development organization, not just the integration team. The application team and the database team and so on will also use it. Everybody will be on board. Sometimes we have seen customers onboard about 60, 70 developers and then maybe a few additional external consumers. However, we also see some customers with very small teams of around 10 people. It works well for both.

How are customer service and technical support?

We've dealt with technical support in the past. There's always that possibility, especially with newer versions, that we might run into some technical issues. However, tech support and issue management are both pretty straightforward.

You can create tickets with the portal on Software AG through Software AG's support portal. They respond within 24 hours usually, and try to resolve the issue quickly. Sometimes the issues might need a product or a quote fix, which might take a day or two. Otherwise, they might be able to look through the knowledge base and give us a solution immediately. 

They have a pretty good response time and offer quality service. We're pretty satisfied with the level of support.

How was the initial setup?

In terms of setting up the solution, the solution offers both cloud and on-premises options. The on-premise license and setup can be done yourself. That can be a little complex depending on what is the overall deployment architecture that is needed. 

However, webMethods API also comes in a cloud form, the webMethods.io, and that is just a subscription. Most of our customers can just subscribe to it and they don't really have to worry about the setup. Everything is already pre-set.

Typically, while the on-premises setup is somewhat complex, we don't really require people to be continuously monitoring it once it's launched. The setup itself might take less than a week or two, depending on the size. 

In terms of maintenance, unless there's a lot of APIs subsequently developed and running, you don't really have too much. Once the customer starts developing a lot of APIs and puts a lot of those APIs into production, that's what will contribute to the support and monitoring needs of the team. 

Typically one person can handle deployment and maintenance. Of course, the cloud doesn't really require the same amount of work.

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

The pricing can fluctuate. I don't have the numbers on hand, however, I can say that they're somewhere in the middle in terms of pricing. They aren't the most expensive or the cheapest. They're priced right for their capabilities and the quality of service as well as the stability and performance on offer. They're well priced for their general offering.

What other advice do I have?

We are partners with Software AG. We've been a partner for more than 20 years now.

I'm a consultant. I work with a consulting company. 

I'm familiar with API Gateway, API Portal, and Active Transfer.

The API Portal and Gateway form the layer of API management, however, usually, API management does not go on its own. There's typically some level of an integration layer behind it as well. Either a customer is applying an API management layer on top of an existing integration layer, or, if not, a customer is starting fresh and has to apply both layers subsequently, or consecutively, kind of like creating an API management layer, and integration, a hybrid integration layer. 

Both go together, especially in data integration, or in application integration and cloud application integration.

I'd rate the solution at an eight out of ten.

Which deployment model are you using for this solution?

Hybrid Cloud

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

Disclosure: My company has a business relationship with this vendor other than being a customer: Partner
Flag as inappropriate