What advice do you have for others considering IBM API Connect?

API lifecycle management capabilities have enhanced our company's operations, and they weren't hard to manage. When we procured the tool, we received some training from IBM. One was for administrators, and the other was for programmers. It was pretty easy to configure it. The only downside is that it requires a lot of physical resources, so we had to get a few servers to work with it. The product is not only used in the government sector but also in the telco and banking sectors. It is one of the biggest products that is being used as an API Manager. The other products would be from Oracle or some other renowned vendors. I would obviously recommend IBM if you are going it for a large scale with APIs and if the number of hits is pretty much huge. I would definitely recommend the product to others if the pricing is not an issue. In my company, we are not using AI with the tool, but it is probably one of the things that is being planned. Until now, AI has not been utilized in the tool. In my company, we have not explored the tool for any other integrations. We just wanted to use it purely as an API Gateway-based product. Considering the price factor, support, and stability, I rate the tool an eight out of ten.

IBM API Connect has dramatically aided our AI-driven projects by increasing developer productivity and facilitating the development process using AI tools. It helped us automate sub-processes and perform thorough analysis for operations and security. I would suggest considering IBM API Connect for enterprises focused on security and enhanced functionality, especially if they need rapid implementation. If they're looking for more advanced capabilities or a broader solution, I recommend exploring options like Google Apigee or MuleSoft Anypoint Platform. Each product has its strengths and focuses, so aligning with the organization's specific needs and priorities is essential. Overall, I'd rate IBM API Connect an eight out of ten.

We use the platform’s analytics feature for extracting reporting for billing purposes. It is a good feature. It offers a sandbox environment where users, such as developers or testers, can interact with and test various APIs. In the subscription process, EVOFRO (Evaluate, Offer, Verify, Fulfill, Render, Operate) is involved, specifically during the consumer's subscription attempt. It triggers a flow that includes reviewing and approving the subscription. It helps us achieve 80% compliance with regulations for our company. I advise customers to identify the use cases before purchasing the product. I rate it an eight out of ten.

We started with DataPower ten years ago. Most of our APIs are SOAP APIs. When we started using RESTful APIs, we started using IBM API Connect. It took us a while to adopt API services. I will recommend the solution to people who need to manage their APIs. It's pretty good. It serves our purpose. Overall, I rate the product an eight or nine out of ten.

I rate the overall tool a seven out of ten.

Overall, I would rate it ten out of ten.

IBM API Connect is a really good API management solution that offers a variety of benefits and advantages such as rapid development tools and enhanced productivity. I would rate it nine out of ten.

I would suggest that if you're looking for stability and excellent performance for your API gateway, you should definitely choose IBM API Connect. Overall, I would rate it as a ten.

The solution is a very, very powerful tool. It has many, many capabilities, apart from it having many, many adapters and integration with the backend to provide you with a comprehensive portal development portal application. This comprehensive portal application can be used by the developers of API since API is a fast and powerful tool. In addition, the analytic part of the tool provides you with full analytics and defines SLA for the APIs, and you can generate the analytics to get statistics about the utilization of API, which most people use. This tool is very, very comprehensive and very, very beautiful. It's very easy to use. And in addition to that, it is an API management tool deployed on an OpenShift platform to give you the capability of containerization for sustainability and agility. So, it's part of the tool. Overall, I rate the solution a nine out of ten.

The solution does not need a lot of maintenance, it is similar to any other verification tool. I would recommend this solution to others. I rate IBM API Connect an eight out of ten.

There are some performance issues and issues related to asynchronous APIs. So, now we are investigating these issues since they are critical ones. Owing to the aforementioned reasons, I rate the overall product an eight out of ten.

I rate IBM API Connect a seven out of ten.

I'd rate it a six out of ten.

It's helpful to have a suitable in-house team and to work hand-in-hand with the system integrator. You also need powerful infrastructure and hardware. If you're exposed externally, you have to apply security standards either on the Gateway or F5, or the Load Balancer. It requires the capabilities for good enterprise or solution architecture and sufficient experience on the integration side in order to have the right solution design and system architecture. I rate this solution eight out of 10.

I'm still working with IBM API Connect. I'm an implementer, system integrator, and reseller of the solution. Mostly I have mid-size and enterprise customers for IBM API Connect, though I also have small-sized customers. My customers use the solution. Most of the customers here in Jordan prefer an on-premise deployment for IBM API Connect, but my company also has cloud implementation, one public and one private, then the rest is on-premises. My advice to people who want to start implementing IBM API Connect is to always start small. You need to understand the value you want to gain from implementing the solution, focus on business values and achieve those, then start to grow bigger later. Don't start with a big environment when implementing IBM API Connect that wouldn't result in any business value. Starting small with real business values that will touch on business needs is good advice for anyone who wants to implement IBM API Connect. My rating for IBM API Connect is nine out of ten because it's a good IBM product. It's one of the products you can easily sell.

I would rate this solution a nine out ten.

I rate IBM API Connect an eight out of ten.

I would rate this solution a seven out of ten.

I would say that if you want stability and security, you should go for API Connect. It's a very robust product that lets you easily create and manage your API. I would rate API Connect as nine out of ten.

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.

The product is easy to use, but the installation is not easy. We have a team of three architects who maintain the product. I would rate this solution as an eight out of ten.

I do integration and I do API management. I do a lot of other things. I don't just use one product. I use various products depending on what the client asks. For API management, I've used X-Ray, WSO2, Software AG, Oracle, DataPower, and Apigee. It all depends on what the customer has. I also have a personal experience with IBM API Connect. How this solution is deployed depends on you. What matters the most are the gateways and the portals. The portals are mainly for onboarding. Whether you'll deploy it on-premises or on cloud is up to you. You can also do hybrid deployment in some instances, because there are people who do hybrid deployment, but the key component for aligning a deployment is mainly the portal and the gateway, because the gateway is the policy enforcement, while the portal is mainly for presentation and onboarding purposes. Other people are running IBM API Connect, but others are not. They just prefer using their hybrid appliances, e.g. the DataPower, so it also depends. There are cases where you can just simply deploy this solution, but it still depends on the policies that you need to enforce. That's why I was saying the key components are the portals and the gateways, because the gateways are doing most of the work. The gateway handles the transactions. It does all the heavy lifting. The portal is mainly for presentation purposes. I've used WSO2 and Software AG, and when you compare them with IBM API Connect, the principles are more or less the same. It's more on how you want to deliver the solution and what the true need of the customer is. You get people who are using it proactively, and that puts the products on the market and drives innovation, but you also get people who are really less integrated people and just build APIs on the portal. It all depends on the use cases and what the customers are offering. The products are all different in a way, e.g. comparable to cars. A Mercedes Benz is really not that different from a BMW. It's just more of the driving dynamics, the comfort levels, and what the brands represent. A BMW will always be sportier than a Mercedes Benz, while an Audi will always be sportier than a Mercedes Benz. This is unless you're going for the real topnotch specs: the AMGs, then it becomes a different conversation. At the end of the day, it depends on the appetite and what their initial use cases are. The number of users of IBM API Connect all depends on the deployment plan of the customer. You get fintechs, e.g. these are mainly coalitions with banks and financial institutions where they try and drive innovation through these tech companies. By giving them access to their assets through portals and APIs, they get to see most of their IPEs realized and used by other parties. These are the people that they couldn't even reach initially. It all depends on the specs and on the range. As for technical people, I've seen that they don't have a preference in terms of tools, but it's a matter of where the product goes that gives them an inclination to stay with those, because that stack gives that effect. It's also a matter of how they can easily integrate with other components, e.g. how they can be incorporated in your two clouds, or your other CMS, to in-house. The user experience is the same as others. The number of users of IBM API Connect can be increased. I've seen a portal that has 4,000 to 5,000 users, and these users are people who create products, e.g. applications. A lot of those apps utilize existing portals and their APIs. What's common on my standard is more payment gateways. Every institution will offer their own payment gateway, and offer a specific sense of liability they are comfortable with. I'm not really recommending IBM API Connect to others. It depends on the investment. For people who are heavily invested in IBM, IBM API Connect is an easy solution, because you already have the underlying infrastructure, e.g. DataPower, which is the most important or expensive component of this solution. For other people, if they don't have it at all, it makes no sense to go the IBM API Connect route if they're using a different stack. As long as the product is working, and it's compliant to specific patterns, it doesn't really matter what you use. What really matters is your budget, what do you have in your storage, and use case levels. If people just want to have something that they can try quickly and dirt cheap, anything else will do, but then, a lot of people are also struggling with adversity, because they feel like the universities or employers are not that heavily invested, and this means they're failing the present capabilities. You just need to show them how the platform works, so it still varies from customer to customer. It's also budget based. From a ranking of one to ten in terms of features, I can rank IBM API Connect as number six. WSO2 is a five. I'd give X-Ray a four. Software AG is a number two. Apigee ranks number one for me. In terms of flexibility, all these platforms are the same. They are the same, but they can be different in terms of target limits. I'm rating IBM API Connect a seven out of ten. I can't give them a ten out of ten, because I feel that they have lost their touch with it.

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.

I rate IBM API Connect an eight out of ten.

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

I would rate IBM API Connect a nine out of 10.

I rate this product an eight out of 10.

I would urge others to use both design time and runtime and not just use it as a repository. I would suggest that they utilize the runtime features, which are pretty strong. First, they can secure your API ecosystem. Second, they have very good monetizing capabilities, which allow you to design products and see who accesses those products. Usage-based and storage-based restriction capabilities are present, which are probably some of the best on the market today. So, I would really urge people to just go beyond the design time and also utilize API Connect in runtime as well. On a scale from one to ten, I would rate IBM API Connect at seven because it is a little bit weak on design time.

I'd recommend the solution to other users and organizations due to the fact that it is very, very easy to use. The product is good, however, that said, they need to pay more attention to their documentation and support. Overall, I would rate the solution at an eight out of ten. We have largely been satisfied with the solution and its capabilities. We are IBM partners.

I'm considering migrating API Connect to Azure. I'm still doing the assessment for this product. That is due to the fact that the move to the cloud is just not only for this product. We have a lot of products in terms of the customer's applications. I need to assess everything together and then propose to my end customer. I'm a vendor. I do assessments for my customer. I wouldn't recommend this solution to other organizations at this time. It's on-premises and everyone is moving to the cloud. It makes more sense to seek out a cloud solution. Overall, I would rate the solution at an eight out of ten.

We are a direct customer and end-user. We aren't a partner of IBM. We're not using the latest version of the solution right now. We have in production the original version - which I believe is Version 5.0. It was the original version. We worked all those years since 2018 and we're having some challenges to go to Version 10 which is the latest version. Overall, I would rate the solution at a seven out of ten.

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

On a scale from one to ten, I would give IBM API Connect a ten.

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

I would definitely recommend trying this product. From a cloud perspective it's there, and from a management of API perspective, all that authentication authorization is quite strong. It's a complete product that you can implement and get a centralized repo of the APIs that you can use enterprise wide. If any other enterprise project comes up, it's worth checking what exists rather than automatically developing from scratch. The solution is very easy to use. It's not really complicated, at least for those who are already familiar with some IBM products. We didn't have a problem getting it up and running. I would rate this solution a nine out of 10.

On a scale from one to ten where one is the worst and ten is the best, I would rate IBM API Connect as an eight-out-of-ten comparing what I know to other products.

I would rate this solution a nine out of ten.

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

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

I would rate IBM API an eight out of ten. I would recommend it. I'd say that you need some time to negotiate the documentation and the conflicting support that's on their website. The website will day to do one thing and in another place, you do something else. You need some time to negotiate that.

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

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.

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

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.

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.

In the 2018 version, the setup is less complicated, but it takes longer. I would rate this solution eight out of ten.