IBM API Connect Reviews

We use this solution for managing APIs.

The most valuable feature is the interface.

The capabilities are very good.

It would be helpful to have access monitoring.

The initial setup is complex.

We have used IBM API Connect in several projects over the past couple of years.

IBM API Connect is very scalable. Our integrations are typically with enterprise-level organizations or SaaS providers.

We normally rely on our internal team for support.

Most of the time, the initial setup is complex. Implementation will take from a few hours up to days.

I would rate this solution a nine out of ten.

Building APIs.

Still working on it.

I have found the API Management to be most valuable.

Business applications could be exposed to users.

We have been using this product for banking, insurance, and government use cases. Perfromance-wise it is very good. It has been improved a lot from the beginning, from API Connect 4, 5, and now we have the latest version of it. The product is available in various forms which gives us the flexibility to propose solutions to our customers.

Any new company starting with APIs, this product is very helpful for learning how they can export their business functions and data to the outside world. It's easier for them to expose their business functions for various use cases.

This product is well integrated with other products. Its ability to interact with IBM Secure Gateway and other products is the core feature. Also, the lead time to put it into production is relatively short and that is something customers are pleased with.

In terms of stability, I think it needs some improvement when it comes to externalizing the analytics data. The analytics collected with this product are part of the product database. If we could push the analytics data to an external data source, the customers could use it for historical purposes.

It is scalable.

Technical support is very good, helpful.

The setup is pretty much straightforward.

I rate this solution a nine out of 10. It has all the core features that allow any small company to start with the API calls. There are Essential, Professional, and Enterprise versions. The product is in many forms, like docker, for example.

I recommend this product. Take a look at it.

The most important feature is, for sure, the security gateway. But if we think commercially, the possibility for easily creating and exposing service plans and charging is also valuable.

We are planning the usage possibilities of API management inside our company, and outside, as well. Plenty of our web services are spread throughout various enterprise infrastructures and we want to control them in a better way with this tool. Of course, the valuable part outside the company is possibility for tracking and exposing telco services, as well as a commercialization aspect, through a developer community.

We have no suggestions so far.

After six months testing the platforms we now have a preparation period for commercial usage. The platform is technically ready for use. We are using a Data Power XG45 v6.0.0.4 as the gateway layer alongside API Management.

No issues encountered.

No issues encountered.

No issues encountered.

We have no such information so far.

We know that our implementer had some problems while implementing the platform but the main vendors technical support (IBM) responded very quickly and professionally.

No, we didn't. This is our first tool with this functionality.

Initial setup is very simple. Later implementation is a little bit complex (disagreement of reference in documentation, different recommended OS versions for additional parts of the environment etc.)

The implementation team did it with the support of a main vendor team. They have high level of expertise.

No we didn't. Maybe ESB (Enterprise Service Bus which we already use) is one of the solutions for exposing different kind of web or other services for sharing usage data but we realized that API management will be more useful for our wider purposes.

It's a good solution with a simple user interface. It has many different possibilities as a business solution.

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 a financial services provider. We have services that we expose for things like investments, policy management, and so on. We have put this on an API Gateway to be able to aggregate all the things that we do for different types of clients with whom we engage.

The exception and error management have been the most valuable feature.  

We take steps for how many transactions we can create. It has a dashboard that allows us to see where transactions are coming from, which clients use it more, etc. This makes it very endearing for us.

I would like to see support for non-Java based services. We struggle a bit to be able to deploy and connect our .NET services because of things like data types. We had to map a couple of things. For one solution provider, we had to move them to .NET Core before we could use it properly. I would like to see more agnostic tool service platforms rather than moving it more towards Java or open source.

Two years.

It is quite stable. We've not had any problem. It has made for a good buy because we are finding that other companies that have similar set ups go down maybe once a month.

Our transactions has been escalating. We're doing an average of about 1.2 million transactions every week now, and it's stable.

We have not tried to scale it. If we go beyond two million transactions a week, we may find more reasons to start exploring scalability.

Right now, we have three clients. The intention is to be able to go to the big investment managers and insurance managers in our sector in South Africa to be able to onboard them. If we have our way, we should have 30 clients, not three.

We don't have a dedicated support with them. However, whenever we send an email, we always get a response back, sometime immediately but maximum 48 hours. They have been very quick.

Previously what we used to do is deploy different endpoints for different clients that we have onboard. In the last two years, what we've been doing is using API Gateway Manager so we have only one endpoint with different uses.

The setup could be made more simpler. We have had to deploy in three instances. The first one had a huge learning curve, though the second one was easier. We find that if we move environments, it takes time to set up. This should be made simpler. We need to do move our BI environment and we have not done that yet because of the setup time. 

The first deployment took almost five days. Right now, we are averaging around a day or two, then we are up and running.

We've played around with other API managers, like Tyk, and the setup is much simpler. 

The reason why we took IBM was because of its resilience and name brand. Our clients trust the fact that we are not just going for an open source or free solution.

One of the key selling points is the easy analytics to be able to analyze what we are getting. We played around with Tyk, but we didn't see any analytics with them. E.g., we tried to connect Tyk to our Microsoft Power BI so we could use that. This feature comes standard with IBM, that's why we're sticking to it.

We have not done extensive checks on Azure because our first client that we onboarded was Google. So, we never really explored Azure that much. In the next six months, we may be exploring Azure so we can have everything in the same space.

To cut down on your implementation time, read the documentation. It's long but explanatory.

I would rate this solution as an eight (out of 10).

We primarily use this platform as an edge computing device wherein we expose our internal capabilities, legacy capabilities, and cutting-edge capabilities, from a standard security point of view. From an interfacing point of view, the social aspect of API management is maintained, and we are looking forward to the proper monetization in API economy with this tool. This solution is deployed on-premises. 

One of the most valuable features is that we can seamlessly and harmoniously expose our capabilities, from a security point of view. 

IBM API Connect could be improved with better monetization and customization capabilities. I work for a Saudi Arabian client and we use Stripe as our payment gateway, but Stripe doesn't have a gateway in Saudi. This means that our monetization capabilities are limited. 

We are also not happy with the portal experience. The API developer portal isn't attractive. We want something eye-catching, but this isn't easy to do because the customization possibilities are so limited. 

Our main pain points are in these two areas: creating a better developer portal and improving stability in terms of synchronization and monetization. 

I have been using this solution since 2019, so about two years. 

IBM API Connect is based on data power and, from a security and stability point of view, it's good. However, we use a 2018 version that has a stability issue. The one problem we encounter is that the syncing between different components of API management is not happening. We had to get the administrator to do some locking, unlocking, things like that. Most of the time, I deploy it, everything is sorted, and the transactions are going through, but at times, we have issues with publishing the APIs. So I sometimes question the stability. 

This solution is scalable. We have a team of 10 developers using this platform to develop and deliver the APIs. We have about 15 different types of users. We are API-led in the architecture that we have right now and every day, we are exposing APIs for new, different types of users, so it's gradually increasing. 

IBM's technical support is good. They help and sort out any problems, so no complaints here. 

From a developer's point of view, the installation is easy. From an administrator's point of view, it's a mess, it's too much. I don't come from an administrative background, but I work as a solution architect in the API space and as a guide to the admin team. I'm not sure what the installation timeframe is, but I don't think it's too much of a hassle. It's Kubernetes-based. I think the hassle comes afterward, if you need to solve an administrative or syncing issue. We have a team of one or two admins and about ten developers. 

We implemented through an in-house team. 

This is a licensed product. If your company is looking to obtain a license, you have to work with IBM partners.

We are also evaluating Apigee. We aren't happy with the portal experience in IBM API Connect, and it looks like the theme implementation and customization in Apigee is much more attractive. This is why we are doing a comparative study of Apigee and IBM API Connect, to see if Apigee would be a better long-term API management platform. We want to see if our customization experience with IBM will be similar to Apigee or if it will be much simpler. 

I rate this solution a six out of ten. I would recommend this solution to others, but I'm not sure my recommendation would be fair since I didn't explore other platforms—I can't provide a comparative study. As a tool, I wouldn't recommend it to somebody looking for an API management platform, due to the limited API monetization capabilities. I would also not recommend it to clients who are working in Saudi Arabia, since there is no support there—they asked us to build a billing solution by ourselves, which we didn't like. I would absolutely recommend it to clients in other Gulf countries like UAE or Qatar, or maybe even clients in Europe or America. We are using version 2018, but I heard that they're coming up with a better solution in the next version. We have yet to explore it, though. 

I like how it runs within DataPower, and adds the extra OAuth security. It gives me a common place to do security for all my API services.

The biggest benefit is the availability provided to the people that will use my services. They can go to a portal and look for services to identify which ones they'll use.

We use it for existing IIB services. We call on multiple back ends from the same service where the record layouts are different. It's difficult to describe and use them in the product.

Actually, we're in production for demo purposes, so I really can't speak to this. So far, we've had no issues.

We have used technical support and we have a good response.

The decision to switch was made before I had left IBM and went to this company four months ago.

When selecting vendor, support and longevity are the most important criteria.

I was involved in portions of the initial setup. It was complex from the standpoint that there were a lot of components, but it wasn't difficult.

Make sure to understand its purpose and what it's used for and not used for.