IBM API Connect Reviews

We have implemented this for four or five banks in Nigeria. The bulk of our clients are banks. We need determine if there are transaction capabilities from their back-end applications. If so, then we consume their APIs. For example, we have a logistics company who uses the bank's back-end API to complete their payments.

We specialize in application and cloud integration. 

We have clients deployed on-premise, on the cloud, and with hybrid cloud.

The workflow allows for different parties to work independently of each other, e.g., business people can work independently of the developers. 

If the rules are well followed and aligned, an organization can run a constant API ecosystem.

Our version supports containerized integration. I can write APIs, which can be moved into a testing environment without needing a forklift. It can check if APIs are compliant before moving them into production. 

API Connects has absolutely helped to reduce the time it takes to deliver new integrations to my clients. Integrations are a lot faster, which is a big selling point, as it reduces cost on the front-end.

The developer can connect to the back-end services and exclude APIs through API Connect. It is very robust, e.g., I can exclude web services. We can paste the code into the UI interface.

Pre-built connectors are good if you need more security, though it depends on the extent to which you use them, as they are not necessary to use.

The solution is very simple and straightforward.

There is room for improvement in the reporting and monetization. With monetization, I want to be able to provide my own pricing and platform.

I would like them to add hooks into the API. E.g., it should be able to check credit, then limit access to people who don't have credit anymore.

They need to have more training for people. 

Since 2017.

There are issues with upgrading in the cloud version. The cloud version is extremely buggy. We prefer to use the on-premise version.

It's redundant so scalability is not much of an issue.

I would rate their technical support as a five out of 10. They are very slow. IBM has been working on this for three years. 

Some of our clients tried to use a customer design. They switched to API Connect because it is more advanced.

The initial setup and development are straightforward. The cloud is already available, so the development is what takes time. Deploying the cloud just takes clicking. It can deployed in minutes. The on-premise deployment takes two or three hours without issues to set up. if there are issues, it could take a day to set up.

It takes one person to set up, max two, as it is straightforward. There is not a lot to do. The system admin will probably spend one to two hours on it to maintain it.

It takes us a week or two to set up 50 services in API Connect. The only thing that might take extra time is portal design because that requires us to go into the back-end.

API Connect is quite pricey.

The developer builds the API and determines what should be put together. However, the business people determine the price.

The product plan and pricing needs improvement. It is confusing to the client based on the way a business might put it together. E.g., I have to be able to pick out different APIs, then group them together. I then have to explain to the client if they subscribe to this API product all the services available. Many clients want a variety of price groups based on their API selection.

I haven't seen anyone go from on-premise to the cloud. In fact, I am seeing people go from the cloud to on-premise because the costs can quickly grow on the cloud. 

If you want to small small, start with the cloud.

The integration is quite fast compared to others. Other companies combine their API platforms, but API Connect is as straightforward as you can get it. 

Oracle doesn't understand the different personas that need to be defined. This is why API Connect is superior to it.

Microsoft is extremely cheap compared API Connect. We are reviewing their solution in comparison to API Connect.

The client needs to understand the service to use it. They need to make sure that they have the back-end infrastructure to support API Connect.

API Connect is known for its light front-end system. Therefore, it depends on what system it connects to on the back-end. It is important to know how it connects to the back-end.

We are not using Cloud Pak, as it is still too new. We are using it in the lab.

I would rate the solution as a nine (out of 10). 

We are using this solution to handle our open API Connection.

Our company mainly has cooperation with institutions, and we are hoping that with this product, in the future we can create easy connections to other institutions who also implement open API.

The most valuable features are stability and security.

The developmental process is not quite user-friendly.

IBM should improve the customization of the API Connect.

The price could be reduced, it's expensive.

I have been using IBM API Connect since August. It is not in production, we are still in the developmental stages.

We have just finished the procurement process.

IBM API Connect is a stable solution.

It's a scalable solution.

The number of users is not relevant. It is based on the number of transactions, not users.

We plan to continue using this product in the future.

IBM technical support is good.

Previously, we didn't use another solution. This is the first API management product that we have used. 

The initial setup is straightforward, and the installation is easy.

We have a team of ten technicians to deploy and maintain this solution.

It's an expensive product.

I would rate IBM API Connect an eight out of ten.

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.

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.

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. 

• API management
• Securing enterprise APIs
• Metering
• Throttling
• Transformation
• Analytics
• Deployment on AWS

• Single entry point for enterprise APIs
• Basic OAuth
• Keys management
• Policy configurations are pretty easy.

• Ease of use
• Security
• GUI is pretty intuitive.
• Easy to configure security and generate API keys.

Components, like caching, should be implemented as policies, not requiring dependency on an external solution. Apigee provides caching as a policy.

In-built policies and security functions.

Integration with DataPower as its API Gateway. Due to bugs in integration, we have to look for workaround on fixing and using DataPower as gateway. 

Have been working on this for three months.

We switched to APIC for easier management of APIs and to leverage its inbuilt policies, security features, and usage of DataPower as gateway.

Setup an "always and anywhere available sandbox" for experimenting and proof of concepts, because one will need to think and experiment much to use the tool.