IBM API Connect Reviews

My company used to work with IBM API Connect for a customer in Greece to run a public sector company from whom we developed a new architecture based on API management last year for the logistics or transportation domains. For the aforementioned project, my company designed a solution based on IBM API Management for the logistics sector of a company all over Greece.

The most valuable feature of the solution stems from its ability in the area of message transformation, meaning it is very easy when you have to transform a message to XML or transfer it automatically from JSON and vice versa. The solution is very scalable. The solution works very well even if you have a small number of users. Our company also tested its use with a large number of users, consisting of more than 2,000 users, and it was very nice to use. The tool is very robust.

The administration of the user interface and the technical documentation are areas of concern in the solution where improvements are required. The solution's technical documentation should be a little bit easier to understand, and it is a traditional problem with all IBM products. The technical documentation is a bit too difficult to understand, and it is also not easy to read.

I have been using IBM API Connect for three years. I operate as an independent consultant.

Stability-wise, I rate the solution an eight out of ten.

It is a very scalable solution.

The meaning of the size of the companies in Greece is very different from what it is in other parts of the world, like the UK or Germany. The tool has around 2,000 users. I don't know if 2,000 users are found in small, medium, or large enterprises, but in the UK, it is a number to describe a small business, while in Greece, it is considered a large-sized company.

I rate the technical support a six out of ten.

Neutral

I rate the product's initial setup phase a five on a scale of one to ten, where one is a difficult process, and ten is an easy phase.

The solution is deployed on an on-premises model. The client with whom I work operates only on an on-premises infrastructure. My client is very demanding when it comes to operating on an on-premises infrastructure. My client is adamant on having on-premises infrastructure owing to security concerns.

I rate the product price a seven on a scale of one to ten, where one is a low price, and ten is a high price.

I rate the overall tool a seven out of ten.

I use IBM API Connect to make migrations with different systems. 

We have used the cloud and on-premise deployments of the solution.

The most valuable features of IBM API Connect are its performance and user-friendliness. 

Improving the documentation would be beneficial as it currently presents navigation challenges. Incorporating a step-by-step guide could facilitate the integration or migration of various systems, including databases. The existing documentation only comprises plain text, hence incorporating more interactive instructions could enhance its usefulness.

I have used IBM API Connect within the last 12 months.

We are having some issues with the stability of the solution.

I rate the stability of IBM API Connect a seven out of ten.

We have approximately four people who use this solution in my organization.

I rate the scalability of IBM API Connect an eight out of ten.

The support from IBM API Connect is good.

I rate the support from IBM API Connect an eight out of ten.

Positive

I have no prior experience using a solution similar to IBM API Connect.

The initial installation was not simple. We had some issues with the deployment but we managed step by step. It took approximately two months to complete the implementation.

We use a team from IBM that assisted us with the implementation.

I rate IBM API Connect a seven out of ten.

I think the most valuable feature is the fact that it sort of combines IBM DataPower being a security gateway with some of the features that are in IIB and IBM App Connect, to kind of build a complete integration. Also, IBM API Connect being the API gateway is extremely valuable both for internal and external consumers of APIs. Off the top of my mind, those are the big points that I would add.

For full transparency, at this point, we brought the solution in and we've used it for a couple of internal hackathons, but we haven't actually used it for any production work yet. Like any bank, it's really forcing a transformation in the sense of the whole industry related to cloud and related to connections to the outside. We're really trying to figure out, internally, how we want to define that.

Some of the other growing pains we've had is, how do we operationalize the technology in the sense of ownership internally; to say, which different groups should actually own which component and how we control the security across that. Personally, my side of the house, which is being responsible for delivering solutions on behalf of the businesses, I'm ready and anxious to get going on it. I'm very excited about the possibilities that the technology brings.

I think that some features that would be kind of cool are around the whole idea of a subscriber being able to subscribe to a plan. Not only should that plan include the number of calls per month or per week or whatever but also, I want to subscribe to a plan with an SLA, which gets into response time of an API call. If the response time in the plan that you subscribe is like 200 milliseconds with a 99.9% guaranteed delivery, then I should be able to subscribe to that plan and then be able to go into it and actually see how close I am to adhering to that.

Internally, this makes for some very interesting conversations right around going from application to application, issuing a connection and they're saying, "Hey, well, we're going to make this many calls a month and this is what we need the response time to be." You could literally say, "Well, we're hitting the SLA." Or, "We're not hitting the SLA." Externally, I think you have the same sort of commitments and when you're negotiating contracts, especially on the larger business partner connection, with the business-to-business connection conversation as well.

Given the fact that it's not operationalized, I cannot really comment too well on the stability because we haven't really had to worry about the stability yet. I'm not really in a place to know. I've heard rumors that there are occasionally some issues related to how it maintains connections with its other pair, but I don't know enough to know.

Based on the architecture, from what I've heard, it's quite scalable. It's just, bring in more nodes and away you go. My understanding is it’s very scalable.

Personally, I have not used technical support.

We did not previously use a different solution. Let's face it: This is a relatively new space and we’re a bank. Of course, we knew that the solution was going on.

I was not involved in the initial setup.

I do believe that there was an RFP process that we went through as part of the selection for this tool. I do not know which other vendors were on the short list.
Usually, our vendor selection process is quite rigid around that. Everything comes into play. Of course, there's cost but then there's, how well it's going to be supported. What does the product roadmap look like? How well does it conform to our internal technology standards? How well will it play within our environment? There's a lot of stuff there.

I think if you're working with IBM and you're looking at possibly using Bluemix now or in the future, the other thing is, if you're using IIB or you're looking at Salesforce, there are a lot of synergies related to these platforms and this tool set, so it sort of makes sense to head down this road.

Personally, if you're a small startup, you might need to evaluate the entire landscape a little bit differently, but if you're a large enterprise and you already have a pretty big relationship with IBM, I think that it makes a lot of sense.

My rating reflects the fact that it's not operationalized at this point, and that's not entirely the product’s fault. I see a lot of potential, but there are still some things that need to be there.

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.

Our use case for this solution, depending on the API Connect centralized team, is for registering any APIs. Once those are there, the main idea is that they have to be reusable and available like a global platform rather than just internal to your applications. API Connect does that, you register your API and it is available. Anybody who wants to use that function or that API can now go through API Connect with the current credentials and get access to your API. I'm a lead architect and we are customers of IBM API Connect. 

This product has provided us with a structured way for anybody who wants to develop any API. It has reduced the amount of time spent on engagement and involvement of the team. They should put it on the cloud and in a mode where anybody can take something like a post run or something and test an API. In that way it saves having to really engage with the source or engage teams. If I want a solution, I can just call API Connect, see that API, test it out myself, and see how it works. Just like an email, there is an API that you can use that can send an email to anybody. I then check how it works and can integrate it with my application. I really don't have to create a work order and go to the team and start engaging them. If it's there you can just started using it. 

Reusability is the biggest most valuable feature for us. The security is also a major feature in some ways because if it's in API Connect, the gateway, you're in and out, it's well organized, rather than having some internal solution where somebody has to manage the in and out. In API Connect, the certificates and all those things are managed pretty well. From a security perspective, it makes things easier. 

From an API perspective, it is pretty strong. Again, it all depends on how other teams are implementing like certificates. If you register you eventually have to request certificates which API registers, so it is secure. From that perspective, I think API Connect has a pretty decent product.

Improvements depend on your perspective and what you need the API to do. I think it has room for improvement because, for example, there's nothing to show that other teams might be dumping the same thing and you have no way of knowing if it's redundant. I feel that sometimes different versions of the same thing are put in there. Although there may be slight differences like including some extra fields, at the end of the day, you're almost dumping the same API again into API Connect. At some point the product should be able to tell you that there is already a similar API there and whether you're dumping an API that's almost identical to what is there.

I've been using this solution for three years. 

This solution is stable. 

This solution is scalable.

The technical support is very good. 

The initial setup is a bit complex regarding what you want to put into API Connect because you're giving to a centralized team that has no idea what API to take and use it for. The centralized team is just a team that has no idea what to collect from these hundred teams. You need to have an idea of what you're taking from them and what they're being used for. That's a bit of a challenge. Again, from a new development perspective, it brings a structural way of development of the future API.

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. 

One valuable feature of IBM API Connect is its role differentiation between API publishers and consumers. Publishers can easily identify, create, and publish APIs on the developer portal, defining plans, packages, and potentially billing rules. Consumers, interested in specific API packages, can subscribe, and use the APIs, and the platform tracks usage meticulously, allowing accurate billing applications for API consumers based on their usage patterns.

The platform’s integration with the payment gateway needs enhancement. The setup process and support services could be improved.

We have been using IBM API Connect for three to five years.

It is a stable product. I rate the stability an eight out of ten.

It is a scalable product. I rate the scalability an eight out of ten.

We encounter challenges related to the availability of local support and time zones.

Neutral

We used another product for API management. However, there were several areas of improvement related to the availability of a knowledgeable and skilled support team.

The initial setup is complicated for container deployment. It is easy to maintain. I rate the process 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 primarily use the solution for a bank. It's used for the operations portion of the bank. It's primarily used for the review of the personnel in your accounts et cetera. It's for many operations for the bank.

The interface is very nice. It makes the solution easy to use and navigate.

You can install it in coordinates, in general, and you can deploy it in Amazon, in Google, in the IBM cloud, or other clouds as well. You don't have to worry about having to work on a specific cloud. It makes it very flexible. This is very important.

The product is quite robust. 

The initial setup is very easy and the deployment is very quick. 

The documentation needs to be a bit better. It's very sequential, however, I don't understand what options to choose for certain tasks. I need to read all of the documentation to find what I need. It's easier to look at recommendations or to watch Youtube videos that show specific examples. 

There needs to be more in the toolkit to complement the product. We could have more features, for example, for queries to the platform. 

I've been using the solution for three years or so. It's been a while. 

The stability has been fine. We've found it to be very stable. There are no bugs or glitches. It doesn't crash and freeze. In the past versions, stability was a bit of an issue, however, in the latest version, we have found it to be much better and much more reliable. We are satisfied with it so far. 

The scalability has been good. If a company needs to expand it, it can do so.

We have an average of 1,000 people using the platform normally. On top of that, there are 10 developers that are also on it at any given time. 

Technical support could be better. They are so-so. They could be more supportive and be better at answering questions. We'd like it if they made issues easier to resolve.

There's also a general lack of documentation, which sometimes means finding answers on your own is difficult to do. 

The initial setup is not overly difficult or complex. It's very simple and straightforward. 

The deployment is quite quick. It only takes about one hour to have everything up and running. 

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.

We use this solution for rest-based, micro services to complete authentication. We are able to gather statistics and audit and throttle traffic. It also has a developer portal that allows users to browse their APIs and develop applications on them. It has solid features compared to some of the API services management services out there.

This solution is ready to scale and already supports our agile CICD.

The integration of cloud-based services is where we're looking for improvement in this platform.

We have been using this solution for four years. 

This is a stable solution. 

This is a scalable solution but scalability would come at a higher price. This solution supports our organization of 50,000 people.

The initial setup is reasonably straightforward.

We consciously decided to go with microservices to enable us to move quickly and to building the flexibility and capabilities in our applications. Whether the business is able to translate those investments into profits and returns is too early to tell.

I would rate this solution a seven out of ten.