What is our primary use case?
We provide social security services (nonprofit) to our tenants and their customers.
Our goal with an API gateway is to separate our own clients in our extranet from the server implementations. We want to provide a unique point-of-contact for the client application(s) while having several server components at the backend side.
Furthermore, we need a single-sign-on solution and mapping of services.
Everything needs to run an OpenShift 4.x private cloud with no (or very restricted) access to the internet.
How has it helped my organization?
Unfortunately, this solution resulted (at least for us) in more problems than expected. We had severe installation and upgrade issues (maybe due to the nature of our network which is closed to the outside). One of those upgrades took, including problem solving, three people three weeks. Luckily, this was not in production, but if it would have been, we would be lost. This is the main reason for choosing another solution.
Also within the specific version, a map operator was missing (which was needed) - so we would need to write mappings on our own in JavaScript.
What is most valuable?
When API Connect is running, it is a stable solution (just do not change it).
Also, managing products and catalogs was helpful and it would be helpful for (as in our case) companies that need to run a multi-tenant concept.
The developer portal is based on Drupal which is in itself very powerful. The service provider view and the consumer view are totally separated (however - the look and feel are also different).
From a starter perspective, using OpenShift, the operators to install are all there.
The statistics component is easy to use. You get your information at your fingertip.
What needs improvement?
Installation is weak. We (three people) ran into so many problems that I would, as an engineering manager, give this back to the development team.
Too many secrets (even if they are set by default, we had problems).
The big footprint of pods, a complex network of them. This should be simplified.
To me, the product looks over-engineered. On the other hand, documentation needs more examples, this is "under-engineered".
They need to provide debugging facility for service implementations and policies (see gravitee.io for an example)
Buyer's Guide
IBM API Connect
January 2025
Learn what your peers think about IBM API Connect. Get advice and tips from experienced pros sharing their opinions. Updated: January 2025.
831,997 professionals have used our research since 2012.
For how long have I used the solution?
I've used the solution for one year.
What do I think about the scalability of the solution?
Although we had our problems, I would say it is very scalable.
How are customer service and support?
Technical support is too slow.
How would you rate customer service and support?
Which solution did I use previously and why did I switch?
We did not previously use something else.
We took on API Connect although it was not Number One on our shortlist as we had a large contract with IBM which includes also this product.
How was the initial setup?
The initial setup was too complex (we had problems).
What about the implementation team?
We worked with a certified external consultant company.
What's my experience with pricing, setup cost, and licensing?
Be sure you do not run into installation or upgrade issues.
Our problems here were caused by our closed environments, however, still, it is in the dark of the systems where the problems are.
Which other solutions did I evaluate?
What other advice do I have?
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.
Which deployment model are you using for this solution?
Private Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Other
Disclosure: I am a real user, and this review is based on my own experience and opinions.