IBM API Connect Reviews

We are using IBM API Connect to integrate bank applications. We are linking frontend services with the backend to prevent unwanted penetration.

I have found IBM API Connect to be highly secure, efficient, easy to deploy, and has a great GUI. It can operate and integrate well with other vendors, such as Amazon, Google, and Microsoft.

I have been using IBM API Connect for approximately two years.

The solution has a modern cloud and it has been stable and reliable. We have not had any breaches of security.

The solution is highly scalable, you can scale up and down. It has good performance, and you are able to customize the APIs to what you want.

The support we have received from IBM has been great, they have been very responsive.

I have previously used Oracle API gateway. When comparing the two, they are both very reliable and have good APIs but IBM on-premise installation is more flexible.

The installation was difficult with the IBM toolkit.

We have an architectural roadmap to follow while doing the implementation of the solution and it took approximately three months for our teams to complete. I had some support from IBM during the process.

The price of the solution is very expensive, it can turn many customers away.

The solution is very good and might not be suited for everyone's use case. Organizations might not need such a robust solution that is priced as high as it is. The demographics can play a role in if this solution is suitable, it depends on what others are using to make it competitive. For example, in Africa, the use of this solution is very low, they are not thinking too much about security. However, if your organization wants to take its operations to the next level then this solution might be the right choice.

I rate IBM API Connect an eight out of ten.

Right now, our use cases are all internal. It's all API socialization internally. With version 10, we'd like to go externally with an actual API marketplace, however, we haven't gone there yet. 

I don't publish; I manage infrastructure. My role is to implement the infrastructure, maintain it, and enable the developers to leverage the technology.

The older versions of the solution were fairly straightforward to install.

The solution offers a pretty good SLA.

We deal a lot with technical support and typically they do help. We need them as we often can't find the documentation that would help us circumvent their services.

We've had some issues upgrading to the latest version of the solution.

The documentation could be improved. When we download a fix that was expected to be seamless to install, it wasn't. In the past, it was easy just to go to any product and download the documentation. If you had the license, you download the product, install it, look at the documentation. Only for specific cases would you have to reach out to support. Now it is like we know that, for these products, we're going to have to call or engage at some point with support. It's painful right now. It's not a smooth installation.

A hybrid cloud enablement would be very useful. We tried to stand up a gateway in IKS and we were told by support that that was not possible. Yet, the technical people, the designers of the solution, started saying, no, you can actually do it. However, they never said is supported, so I was never sure where the solution stands on hybrid clouds. 

The answers that sometimes are provided are not very comforting. If it isn't a full commitment it isn't going to work.

They need to make it a product that can be downloadable and installable and workable without having to engage with them directly.

I've been using the solution extensively for at least the last 12 months. We've been working with it since at least 2017. It's been a few years at this point.

Since we're mostly talking about Version 5, which is a very old version, I would have to say that it is not scalable. The memory gets too high and it affects operations. We had to request another server and it cost us money, even when we were doing a migration. Even if we wanted to go to Version 10 we have to still apply what is called a Fix Pack to the old version to have a separate infrastructure.

We have about 100 developers that use the solution currently.

We have to go through the levels of support. We open a ticket and then we try to engage. I have contacts that I can go directly to. However, if the documentation was better, we would need to interact with them less.

We are currently looking to change over to another vendor.

I actually did the initial setup for Version 5.0 which took a long time to install. It was easier, I think, as we're moving to newer versions. It is due to the fact that we've included Kubernetes and this style of installation that we're doing today which is a little bit more complex. 

The original was not nearly as complex as it is today. 

We're having some issues. If I go from Version 5.0 and I want to upgrade to 2018, I have to request new servers and then migrate all of the APIs. This is the same for Version 10 which wasn't a commitment, however, there was a communication that they would have an upgrade in place by the end of the second quarter and it didn't happen. We spent all 2018 to 2020 installing Version 2018. Now, we're told if we want to go to Version 10, we have to set up new infrastructure.

We tried to do the 2018 installation in three or four weeks and we handled it all in-house.

I cannot speak to an ROI.

We have an SLA we can draw from. I need to keep within certain numbers, however, I don't have a problem doing so. I can't speak to exact costs.

I haven't had a chance to compare the solution to other products yet, however, the plan is to move away from this product. We still need to do the research.

We are a direct customer and end-user. We aren't a partner of IBM.

We're not using the latest version of the solution right now. We have in production the original version - which I believe is Version 5.0. It was the original version. We worked all those years since 2018 and we're having some challenges to go to Version 10 which is the latest version.

Overall, I would rate the solution at a seven out of ten.

One valuable feature of IBM API Connect is its role differentiation between API publishers and consumers. Publishers can easily identify, create, and publish APIs on the developer portal, defining plans, packages, and potentially billing rules. Consumers, interested in specific API packages, can subscribe, and use the APIs, and the platform tracks usage meticulously, allowing accurate billing applications for API consumers based on their usage patterns.

The platform’s integration with the payment gateway needs enhancement. The setup process and support services could be improved.

We have been using IBM API Connect for three to five years.

It is a stable product. I rate the stability an eight out of ten.

It is a scalable product. I rate the scalability an eight out of ten.

We encounter challenges related to the availability of local support and time zones.

Neutral

We used another product for API management. However, there were several areas of improvement related to the availability of a knowledgeable and skilled support team.

The initial setup is complicated for container deployment. It is easy to maintain. I rate the process an eight out of ten.

We use the platform’s analytics feature for extracting reporting for billing purposes. It is a good feature. It offers a sandbox environment where users, such as developers or testers, can interact with and test various APIs.

In the subscription process, EVOFRO (Evaluate, Offer, Verify, Fulfill, Render, Operate) is involved, specifically during the consumer's subscription attempt. It triggers a flow that includes reviewing and approving the subscription. It helps us achieve 80% compliance with regulations for our company.

I advise customers to identify the use cases before purchasing the product. I rate it an eight out of ten.

We use this solution in a hybrid way. All the processes and data is in the cloud but the API gateway is part of the API Connect solution and runs on prem in Argentina, connected to the cloud.

The management of the API and API portal is good. 

The monetization of the API could be improved. The pricing for the consumer is also very important to improve this solution. Nowadays, we are sending information to other tool in order to process out of API Connect. They could improve this internal service in order to have the balance for the consumer's API for different companies, external to our company.

I have been using this solution for three years. 

This is a strong and stable solution. 

The initial setup is complex. When setting it up, you will need support. We are using AVP support from IBM. Its an extra support service. I would recommend using this kind of support because it will help your company move quickly in order to set up the different products. IBM AVP stands for accelerated value program.

I would rate this solution a nine out ten. 

We provide social security services (nonprofit) to our tenants and their customers.

Our goal with an API gateway is to separate our own clients in our extranet from the server implementations. We want to provide a unique point-of-contact for the client application(s) while having several server components at the backend side.

Furthermore, we need a single-sign-on solution and mapping of services.

Everything needs to run an OpenShift 4.x private cloud with no (or very restricted) access to the internet.

Unfortunately, this solution resulted (at least for us) in more problems than expected. We had severe installation and upgrade issues (maybe due to the nature of our network which is closed to the outside). One of those upgrades took, including problem solving, three people three weeks. Luckily, this was not in production, but if it would have been, we would be lost. This is the main reason for choosing another solution.

Also within the specific version, a map operator was missing (which was needed) - so we would need to write mappings on our own in JavaScript.

When API Connect is running, it is a stable solution (just do not change it).

Also, managing products and catalogs was helpful and it would be helpful for (as in our case) companies that need to run a multi-tenant concept. 

The developer portal is based on Drupal which is in itself very powerful. The service provider view and the consumer view are totally separated (however - the look and feel are also different).

From a starter perspective, using OpenShift, the operators to install are all there.

The statistics component is easy to use. You get your information at your fingertip.

Installation is weak. We (three people) ran into so many problems that I would, as an engineering manager, give this back to the development team. 

Too many secrets (even if they are set by default, we had problems).

The big footprint of pods, a complex network of them. This should be simplified.

To me, the product looks over-engineered. On the other hand, documentation needs more examples, this is "under-engineered".

They need to provide debugging facility for service implementations and policies (see gravitee.io for an example)

I've used the solution for one year.

Although we had our problems, I would say it is very scalable. 

Technical support is too slow.

Neutral

We did not previously use something else.

We took on API Connect although it was not Number One on our shortlist as we had a large contract with IBM which includes also this product.

The initial setup was too complex (we had problems).

We worked with a certified external consultant company.

Be sure you do not run into installation or upgrade issues. 

Our problems here were caused by our closed environments, however, still, it is in the dark of the systems where the problems are.

We also looked at:

• MuleSoft
• Kong
• Gravitee
• KrankenD
• WSO2

People should also consider support. We had several times to contact the support, and quite often we got a response after some days of the kind "please send this or that additional information". This does not help to solve quickly.

We used API Connect for OPIE management. About 50 developers in my company are using it. 

API Connect is a good product, and everything works fine. All the analytics are good, and it is easy to follow up. I like it in that sense. I'm more focused on following up on analytics by seeing how many API calls we are getting and where we see a lot of problems. I was working on that API level.

We used API Connect for at least three years.

API Connect's stability was okay. We ran it on top of the Kubernetes cluster, so it wasn't a standalone service. In the worst-case scenario, API Connect couldn't stay online if all the containers went down. We had to restart all the services. We shut down all the containers automatically one by one. That was the only problem. It didn't happen often— maybe three or four times in two years — but it was still somewhat problematic. API Connect is not fully cloud-native in that sense.

We outsource maintenance to a local company in Finland. They built it for us and maintain it.

API Connect was highly expensive for us, but the decision to switch was made before I joined the company. It seems like the company bought it, but they didn't know how to use it. After two years, they decided to reevaluate and conduct some cost estimates. 

I rate API Connect eight out of 10. If you are using a microservice like Kubernetes, that should be tested to ensure it's working. If you are running API Connect on top of Kubernetes, you trust that you can update the Kubernetes cluster on the fly during the daytime.

In our case, every time we had to update the Kubernetes cluster that API Connect was running on, it was so much work. We could update all the other clusters with no problem. So my advice is to make sure that it is working. Otherwise, I think everything was okay. 

We are using it for some applications that are useful for banking.

It is easy to use and stable.

It should be cheaper.

I have been using this solution for a couple of months.

It is stable.

It is scalable. We have around 1,000 users. We have a technical team of 10 to 20 people. They include managers and developers.

It is easy to install. It takes one or two days for deployment.

It should be cheaper. It has a yearly licensing.

I would rate IBM API Connect a nine out of 10.

It is the go-to solution for API repository products. We use it for runtime by designing certain products, and those products are subscribed to by various consuming systems.

It has made API monetization quite easy. I can simply log onto the API dashboard and see who has used how much and whether they are using their quota or not. If they go beyond their quota, I can then give them a higher rate. Thus, it has helped us with API monetization.

We really like the runtime capabilities of IBM API Connect. The creation of products and the control of the monetization and hit rate are some of the features which we've found very valuable.

There are certain areas that need improvement. The first one is the design time setup. It has a lot of customizable fields, but we need certain standard fields to be added, such as what all of the consuming systems are. This needs to be very clearly articulated during the design time.

The second, which was a very big issue for me for adoption, is that they don't give any out-of-the-box solutions for knowing how many users have logged on during the design time and who has access to the portal for how much time. There is no capability right now to tell me the usage details and user rights.

As for additional features, design time user analytics would be great to have in the next release.

I've been using this solution for one and a half years.

It's quite stable.

Right now, we are using the design time thoroughly, but we are in the nascent stage for the runtime. So we just have a couple of systems using it, but going forward, we have plans for extensive adoption of the runtime capabilities.

We were previously using WSRR, and we switched because IBM stopped providing any updates to that product. Also, it was primarily design time only; there was no runtime capability.

The initial setup was a little bit complex because we wanted to put it in a proper Kubernetes cluster. So we had to learn Kubernetes and then do it.

It took us a month to deploy the solution.

We used IBM directly for implementation. We've been using IBM services for the past 13 years, and we are okay with their level of expertise.

I would urge others to use both design time and runtime and not just use it as a repository. I would suggest that they utilize the runtime features, which are pretty strong. First, they can secure your API ecosystem.

Second, they have very good monetizing capabilities, which allow you to design products and see who accesses those products. Usage-based and storage-based restriction capabilities are present, which are probably some of the best on the market today. So, I would really urge people to just go beyond the design time and also utilize API Connect in runtime as well.

On a scale from one to ten, I would rate  IBM API Connect at seven because it is a little bit weak on design time.