IBM API Connect Review

Helps with API monetization but needs improvement in design time setup


What is our primary use case?

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.

How has it helped my organization?

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.

What is most valuable?

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.

What needs improvement?

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.

For how long have I used the solution?

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

What do I think about the stability of the solution?

It's quite stable.

What do I think about the scalability of the solution?

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.

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

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.

How was the initial setup?

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.

What about the implementation team?

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.

What other advice do I have?

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.

**Disclosure: My company has a business relationship with this vendor other than being a customer: Partner
More IBM API Connect reviews from users
...who work at a Financial Services Firm
...who compared it with 3scale API Management
Learn what your peers think about IBM API Connect. Get advice and tips from experienced pros sharing their opinions. Updated: June 2021.
511,521 professionals have used our research since 2012.
Add a Comment
ITCS user
Guest