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 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 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.

We primarily use this solution for the regulation of open banking.

It still does not support open API 3. Another problem is the designer. I want the whole solution to be on the cloud. For the installation, I have to install locally. There are many improvements it needs if I want to implement a MockServer or sandbox. In the future, I hope it will be more intuitive for building a MockServer.

In the next version, I don't know if they've already been included it or not, but the designer and all the tools should be on the cloud. I don't want any external installation or local installation. The old designer should be less complex and more simple or intuitive for you to search as well.

I found the solution to be stable.

The solution is very scalable because it's on the cloud, adding more resources to improve redundancy or performance is simple and configurable.

I've found technical support to be very good.

The initial setup was not as straightforward. Deployment takes a few days. You don't need too many people for the deployment and maintenance of the solution. 

We were working with IBM for the implementation.

We are testing and I'm working for the Bank of Israel and we have to implement the regulation of the PSD2, the open bank, open banking, open API. We would implement it on API Connect, so it's not a production system, it's just a sandbox.

In terms of advice, I would suggest anyone to verify that the product support is the latest version and to find out the frequency of the new versions of the product itself. I think it's very important to go through a project like this before implementation.

I would rate this solution seven out of ten. I'd like it to be more cloud-based, for the open API 3 because currently all the specifications are published only on the API so you have to downgrade it and then input it into IBM.

We primarily use the solution for distribution.

The technical support and the user interface are good.

IBM is also a bit pricey. On top of that, they have bugs that need to be fixed.

The solution is very stable.

The solution is not scalable.

Technical support is okay. I had to call once for billing. We also had a connection issue. They didn't answer very quickly unfortunately.

We didn't previously use a different solution.

The initial setup isn't too hard, but it's not easy either. We didn't deploy anything. We just added a gateway.

We used a local broker to assist in the implementation.

Right now, we are evaluating other options, including Axway, Apigee, and Tyke.

In the 2018 version, the setup is less complicated, but it takes longer.

I would rate this solution eight out of ten.

We currently use it as our single point of the security catalog for the APIs that the bank has.

The developer portal has been the most useful feature.

Like any typical IBM infrastructure setup, you need to learn to set it up yourself. It's not one of those simple zip files or an archive unzip and you're up and running in some few minutes. Knowledge to set it up is key. 

A more user-friendly portal could be helpful. Something you won't really get lost in. For example, other APIs make it so easy to do a couple of things from the portal, not at the management portal itself. Maybe if IBM can improve on that, it would be most helpful.

The system has not been put through real stress. We use it for our third-party APIs and the connection and so that's not too much stress. I can't give a metrics on its stability. And then at the point of setup, we were already getting a bit of redundancy.

We have knowledge of how to add additional APIs to it. With that, if I were to measure on a scale of one to five, I'll put that at four out of five in terms of scalability. Four meaning it's pretty easy. Once you have the knowledge it's pretty easy to add new APIs to your catalog, create a new catalog, etc. As to if the infrastructure itself is it scalable, I'd put at a two because I remember while we were trying to set up a redundancy we wanted to add an additional protecting node and it took us a day or two to get our head around that.

In our country, there are regulations that don't allow us to really engage and that requires us to go through a proxy to IBM. I can't evaluate their technical support since I have never used them.

The initial setup is complex. Deployment takes about two weeks for different portals. The knowledge takes up time and then there are some other internal processes, but if I were to take out the internal process I would put implementation at about a week.

The way our organization is set up, we have a team that is responsible for infrastructure setup. We also have a team that is responsible for activation setup. So, a three-man team should be able to do the setup.

During the setup, we had to get some professional help from IBM itself. We have people that got trained on the solution, and in terms of integration, they got trained on it. And so they will have knowledge on how to create new integrations and new APIs on it and how to expose APIs on it going forward.

Before choosing IBM API Connect, we looked at 3scale API and API G-Box.

Infrastructure setup was a bit painful. Knowledge up-take was not too painful if you are not doing anything complex. But when you start getting into complex APIs then maybe you need some bit of patience if you decide to use this solution.

At the end of the day, it's a great product, I can't fault it for now. We haven't extensively used it, so I really can't say how it would perform over time, or what kind of issues it would have if it was enterprise-wide. I can't find fault with it, for now, it's doing good.

I would rate the solution of seven and a half out of ten.

My point of view is a bit stiff because I'm a developer. I don't mind going through some tech rigors. But looking at it from a more general standpoint, I don't think anybody wants to go through the process of some technical learnings. In terms of the knowledge base, it's not too fun for developers. In terms of setup, it's almost definitely not fun. Usage is working well and based on the architectural principles we are already facing some bit of redundancy on that.

Building APIs.

Still working on it.

I have found the API Management to be most valuable.

Business applications could be exposed to users.

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.