IBM API Connect Reviews

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.

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.

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. 

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. 

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.

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

API Connect is reliable.

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.

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. 

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. 

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.

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. 

We use this solution for external API spotters and API.

It helped us mainly with the corporation, ownerships with other partners.  

It makes it possible to create close companies with processes to develop mutually, and digital solutions. 

This is our main benefit.

The suite itself is what I find valuable. It has all of the tools that are needed for the specific mission. I have the portal, I have the run time and the security.

The solution itself is valuable.

The automation and the simplicity could be improved.

They could also have more frequent additions.

I would like to see the simplicity improved to make it very easy to deploy and to make it very easy for the regular developer, not an API special developer.

I would like the developers to be able to develop APIs and to make them more accessible.

I would also like to have a DevOps built-in process that is very fast and easy.

The monitoring suite should be ready-made and not have to tailor-make my home.

I have been working with IBM API Connect for three years.

It's a very stable solution.

Our work is very basic. We have not dealt with scaling.

It's IBM, and they take time. I am from Isreal and the support is always from abroad. It's a heaving process.

At times when we have issues and have decided not to turn to support since we know it will take time, and the effort is not as understandable, but we will have a solution at the end of it.

Technical support is an area that needs improvement.

The installation is pretty complex. 

We must also take into consideration that I am referring to the on-premises installation, which by definition is much harder, and relatively speaking it is a bit complex.

It is quite an expensive product.

I would rate IBM API Connect a seven out of ten.

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.