IBM API Connect Reviews

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.

It gives a holistic environment for us to set up the APIs and that's the main value that it adds. It gives end to end for us.

We moved from another manager to this one and latency has improved a lot. It has improved the latency response by maybe 20-25%.

In fact, we have had a discussion with IBM and it's agreed upon that they would give us the features that we have asked for, just in three months. We have asked IBM for scalability and for some other features that we wanted. We had a dialogue with them and in the end, they have agreed to provide us with features related to API setup and security. They agreed to give it to us in three months, so we are happy.

In regards to the stability, we are new to it, so it is OK right now. We haven't put much into it yet.

The scalability we have not tested yet; we are testing it now as we speak.

We do use technical support and are in constant contact with them. They are very good.

Previously, we were using Layer 7. The reason as to why we decided to switch solutions was because the current environment was not working for us.

I was involved in the installation process to some extent. I am from architecture, so usually the infrastructure team would be involved.

There are several other solutions that we evaluated but it depends on the capability that we are looking at.

Initially, we started off with one solution and then, moved on to another, as we found out that it's not helping us.

We do several things before selecting a vendor. It's not in my purview, but we do the product evaluation as well. Obviously, IBM is a big vendor and we are a big shop of IBM.

Go for it!

Getting a perfect rating depends on the product and how they give us support or not. We haven't gutted it, thoroughly. It is in production, but it's not perfected. Maybe in six months or more, we'll know more about it.

The most valuable features of this solution are:

• Integration with multiple services,
• Providing security,
• Being able to monitor, and
• Enabling customers using the secure gateway.

We belong to the healthcare industry, so it is beneficial to implement the API Connect solution to provide APIs that can integrate outside and inside our organization. It also provides overall solutions, i.e., API-based solutions to all the customers that we have.

I would like to see more caching and monitoring features implemented in future releases. It also needs to be a more customizable and flexible product.

In terms of stability, we are still prototyping the product. We have the older version, which is now stable, but the current version or the new version, that we are still prototyping, is still not 100% stable.

The scalability is pretty good.

We have used technical support. I would probably give them a 7/10 rating.

I was involved a little bit with the installation process. I found it complex, as there were lots of configurations involved in setting up the infrastructure and that everyone didn't have experience with.

We looked at several other solutions, i.e., both IBM and non-IBM products. However, since we had already used IBM DataPower, we thought we could reuse the same infrastructure. API Connect has DataPower built-in to it, thus we tried to reuse some of the existing functionalities.

The most important criteria while selecting a vendor are the product's support and operations.

Our company is an early adopter of this product so I would advise, at this point, to wait and then implement the solution.

We've yet to realize real value in the solution. The goals that we were trying to achieve from it were to implement microservices and a lot of the features and functionality that were part of the documentation, but we haven't achieved success with it yet.

The benefits would be that we'd have a great platform for our microservices and API management. But since we haven't had a lot of success with it yet, it's been frustrating.

I would like greater stability and greater ability to actually administer the product without needing to go to technical support. It's very proprietary and support has secret passwords that they use to get into certain functions.

IBM has limited the capability for executing typical admin commands and only provide a small list of proprietary commands. Without a secret command line password, clients are limited to what they can view and administer – even in a read-only mode.

Stability is not good.

Scalability is good.

I would rate technical support fair, at best.

We weren't using a different solution. This is a new approach. We do have alternatives that we are using, including other IBM products. But we did this one more from a sales relationship, technical sales team pitch.

When selecting a vendor, reliability and experience are most important; the fact that we had experience with them. We have a lot of IBM products and we had a lot of good relationships.

I was involved in the initial setup and it was somewhat complex; medium complexity.

We didn’t look at other vendors.

Certainly look at other options that are out there and absolutely go with the latest and greatest version of the product, because there have been a lot of issues and it's going through growing pains. It's not completely mature.

We help systems integrators and vendors in choosing different types of platforms for building an open API gateway for banks. We evaluate and test different types of API gateways. We follow our internal testing scenarios to make sure that the product meets requirements. This is all we do.

API Connect is a very good platform for the development of APIs.

They seem to have left out a feature for microservices and also a certification module for OIDC. So it would be a good idea for the authentication module to have OIDC certification.

I have been working with IBM API Connect for about half a year. 

As far as I know, there haven't been any issues with the stability of the solution.

There are also no issues with the scalability.

We don't have any connection with IBM.

The initial setup is pretty straightforward.

I am also familiar with Xware and WSO2 API Manager. They have a different type of development cycle and features compared to API Connect. It's on the development side that they're different. It depends on the type of application.

I would recommend API Connect to a vendor or financial institutions that are looking at using it. It's a nine out of 10. It's missing the authentication module so programming and customizing that takes a lot of time.

Most of the business value that we are getting out of this solution, is that it provides DevOps integration and a catalog for microservices. We are able to share those APIs instantly within the organization; even if we want to share it outside publicly, then we can have those capabilities.

There is a trend to move towards microservice-based solutions, where we have to decouple all our legacy SOA-based services, when sometimes it takes an iterative approach to come out with what you need. Instead of that, we have this microservices solution, where you can just enable the required part in quick delivery using DevOps. These are the main benefits of this product.

Mostly, I would like to see more tools that are DevOps-friendly. We would have more capability to interact with the catalog and inventories, so a more DevOps-friendly solution is needed.

Stability has still not matured. We are still growing with the industry. We will find out after some time how it is going. But, as of now, it's stable.

Right now, in terms of scalability, everything we have is on-premise. However, we have this Bluemix capability, with which we can scale as and when we need.

We have used IBM professional support/premium support. We use them for any of the solutions, such as if we need some guidance on the future roadmap as to how it's going, etc; we engage them. They are excellent. They are always not only there to help us resolve the problem, but also to be able to guide us as to how the trend is going and what we should start thinking in regards to those changes.

We have this monthly inter-tech meeting, where we go through as to what is going on in the market, how the industry is going, and how we can utilize that in order to start serving the business, with an expedited return on the investment. So, this API, DevOps, and microservices are the things which are happening right now.

The most important criteria while selecting a vendor are that they should be able to help us not just with solving problems, but they also need to advise us in terms of how the trends are moving and how we can be strategic partners, instead of it just being a one-time solution.

Advice depends; if you have a preferred technology and IBM has a solution for that technology, then I'd definitely advise you to use more microservices with the API Connect and the DevOps, to provide quick returns for your business. It will be more valuable to you.

My customers are using IBM API Connect for integration in the financial sector.

The most valuable feature of IBM API Connect is the security of the protocol.

IBM API Connect could improve the security of the application and the integration.

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

We have seven users using IBM API Connect and plan to increase the usage.

The technical support from IBM API Connect is good.

I rate the support from IBM API Connect a five out of five.

Positive

We pay for the IBM API Connect monthly. We only need to pay the standard licensing fee.

I rate IBM API Connect an eight out of ten.

This solution is primarily used for workflow applications. Specifically, it is used for web applications with complex workflows that have many users.

The solution helps. We have Domino servers for all our web applications.

The ability for all of our web applications to share standard functions and documents easily is valuable.

Automation for our Domino applications could be improved.