IBM API Connect Reviews

Extracting the data could be improved.

My team members sometimes find it difficult to get something out of this solution.

I have been using it for the last year.

We have no issues.

The scalability is good.

The technical support is good. Whenever we need anything, we have our IT team work with IBM to change whatever requirement is needed.

I previously used the IBM Tivoli Monitoring tool before joining my company.

The initial setup was straightforward.

The pricing is too expensive with IBM. Sometimes, we prefer to go with an open source or something more lightweight.

I can recommend this solution and would rate it as an eight (out of 10).

We have done many implementations using API Connect. We work with some of the largest financial institutions in India, including life insurance companies and some of the banks. 

We have done most of them on-premise. The customers, because they are financial institutions and insurance companies, prefer to have this on their own premises and their own data centers.

It allows enterprises to expose some of their tech to outside stakeholders.

We have been implementing solutions with IBM API Connect for five to six years.

I would like to see automation of the installation. If there could be a single-click function where you could automate everything, that would be helpful. There should also be tools to automate the migratation from the older versions to the newer version. That would be another point that would bring my rating of it closer to 10 out of 10.

IBM sets the pricing, but it would be a good idea to bring down the pricing by at least 20 to 30 percent.

I would certainly recommend IBM API Connect for clients who are going with an enterprise version of implementation and when they have enough budget. Of course, if they have budget limitations, they can consider open-source solutions.

As implementers, we have a big resource pool here in India. All our associates have expertise with API Connect as well as IBM App Connect.

As of now, it is serving the needs of our customers. It is quite a proficient tool. It satisfies all of our requirements.

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.

This solution enabled our business to get our solutions quite fast. Instead of waiting for weeks, or even months in some cases, it actually helped the movement from a bimodal to a faster depth of solution in a matter of the rate at which the organization could change. It was not a technological hindrance, it was more a change management aspect of the people that kept the movement back. But, we proved that the technology can keep up, it's the people that have to change faster. The fact that the product can provide both security and scale to quite a large number of products, is basically the reason why we chose it, and that's what we like about it.

The most valuable feature is the security we get from this solution. I know of a bank that uses it to ensure that everything is secure. The second feature I like is the retail environment, where we actually want to be able to provide as many suppliers and consumers with APIs as possible. If you are well-trained in the writing of RESTful API's, you can actually publish an API in a matter of minutes, test it, and publish it.

It is still a very new product. We're still finding our feet on the latest version of it because it gives you the capability to move into the cloud. We have not yet taken that leap into cloud because of the uncertainty of what the moving parts are, and that's why we'll have to wait and see. I would like to see more stability, however, and I do believe the newer version will offer that.

The new version is very unstable. There are a lot of fix patches and a host of known errors. They've started it on their website. So we're waiting for some of that to stabilize before we continue, but we're working around that as far as possible. The old version 5 was quite stable. We were able to put a lot of business commercial APIs in place. It is actually being monetized, and the guys are making money out of that. 

This is a robust system that is easily scalable. When it comes to the amount of users, it all depends on how you tackle the implementation, because in the first case, we basically had people that's running the infrastructure, setting the infrastructure up, and there you need a number of roles to set up the ecosystem itself. Then you must have the API providers. That could be including some business people as well as some testing people. And then obviously the running of it is basically minimal. With the new approach, we have very few people that can actually do the job. You have to, on a case-by-case, request time from people to do some work for you. There's no dedicated staff. The whole business approach and the whole implementation approach varies from organization to organization.

We plan to increase usage because if you want to make a business digital, that is one of the routes to go. Obviously, if you want to get mobility included in your portfolio of services, you have to go that route.

We've had no hassles with IBM when it comes to technical support. Whenever I log a PMR, they respond. In one instance they actually drove a guy in from their site to come and do a site visit. In another case they flew a guy in from Germany. They know that they have us as a customer and that's why they provide us with good support.

It is not too difficult to work on the solution itself, but to get it to fit within the organization, is something else. There is a vast difference between business models, between a banking setup and a retail setup. One must, first of all, get the business-aligned, because today business plays a bigger role than in the past. With APIs, it's inside-out thinking, meaning that business owners of the data will have to decide how they're going to do it, which is a change in some organizations where IT normally drives the technology. Now, all of a sudden, you have to tell the business, "You have to make decisions which IT will enable".

We used a team of people to implement the solution, and the first time we installed it, we had to pivot twice. All in all, it took us six months, and we had a dedicated team of about 15 people to do it. Once we'd pivoted twice and experimented with it, it took us approximately five months to get it up and going. The latest product, the new iteration, is run through a project, which doesn't have dedicated staff, and it has been ongoing for almost 13 months now. We're not yet done with pivot one.

We used IBM directly because we bought the product from them. We basically got them onsite to explain what their blueprint meant. The documentation was quite good, so all we had to do is get them to come and agree with the pattern we've selected. Now we're still finding our feet, experimenting and making up our minds.

We do see an ROI, because, in the past, we could not monetize services. Now we can sell our data. 

The basic appraisal based on the two models is available on their website. The one is PVU-based and the other one is consumption-based. But that is a ballpark figure. Obviously, when you engage with them in a contract, they can negotiate. 

We did evaluate a lot of other options. We were led by Gartner and Forrester with regards to that, and then we did site visits to other companies that implemented products, and we had a look at their solution. We spoke to some of their staff. Based on that, we did the due diligence, and then we selected the product. This solution came out on top.

The product itself delivers on what is documented and we don't need any additional features. Currently, there are some features that are not working because of known errors. I would like to see an improvement in the stability, however. Once we've got it stable, we can push the limits. We can see what works and what doesn't work, and then we can comment on what is required for the future. I will, therefore, rate this a seven out of ten.

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.