What is your primary use case for IBM API Connect?

I use the solution in my company as an API Gateway and API Manager. We use a few of our products for technical documentation and API Specification, as well as as an API Manager. The rate limiting comes with the tool. It has been a very good product that we have been using for the last few years.

We use IBM API Connect primarily to expose APIs for various information systems in Terra and to integrate with our audit partners.

We use the solution to monitor, process, and manage API services.

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.

We use it for API integration, particularly in conjunction with the One Link solution. One Link is a platform that comes into play during cross-channel communication within the banking sector. For instance, if a customer has an account with Bank A and wishes to withdraw funds from Bank B, it facilitates cross-selling communication between two distinct banks—Bank A and Bank B. Our primary focus is on enabling seamless transactions between different banks, and we also incorporate case and bundle links within our solution.

We have implemented this product in different domains, such as insurance and banking.

We use IBM API Connect for the external gateway for integration, and it is for multiple customers with the external button.

We utilize IBM API Connect for our B2B operations, and occasionally we extend its use to B2C as well. However, our B2B scales outweigh our B2C usage.

The primary use case of IBM API Connect is for API monetization in the banking and financial sector. This involves API management and creating APIs for financial institutions, which is the main use case. Another use case is having all API integrations in one place. A third use case is opening an API and sending the documentation to external third parties.

I use IBM API Connect to make migrations with different systems. We have used the cloud and on-premise deployments of the solution.

We're trying to make our business available on the net so that partners can connect, and distributors can use our services.

We are a regulation entity dealing with many sensitive services. We carry out supervision and regulation for FinTech companies and other financial institutions. We are partners with IBM and I'm the project delivery director.

Our use cases for IBM API Connect include the banking sector, where they use the solution to integrate with third parties, so all of the third-party connectivity for the banks happen through IBM API Connect. We also built the government service website, for example, e-Government services, and the government published all services between the government entities and the businesses, so there are two connections: government to government and government to business. All the services and entities were published and consumed through the IBM API Connect gateway.

We use this solution in a hybrid way. All the processes and data is in the cloud but the API gateway is part of the API Connect solution and runs on prem in Argentina, connected to the cloud.

My customers are using IBM API Connect for integration in the financial sector.

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.

API Connect is mainly used as a gateway solution to expose, secure, and manage APIs.

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.

We deploy APIs to expose the BFFs of mobile apps, and this is mainly in the cloud. All mobile apps consume the APIs of your BFF. On-premise, we have APIs that expose services and mainly functionalities, such as the balance of the client or the customers or the products.

We used API Connect for OPIE management. About 50 developers in my company are using it.

I use IBM API Connect as a black box, I only consumed the APIs that it provides.

We primarily use this platform as an edge computing device wherein we expose our internal capabilities, legacy capabilities, and cutting-edge capabilities, from a standard security point of view. From an interfacing point of view, the social aspect of API management is maintained, and we are looking forward to the proper monetization in API economy with this tool. This solution is deployed on-premises.

My clients mainly use API Connect as an API gateway. A lot of the backend services need to be exposed to other parties, mobile devices, interfaces, etc.

We are using it for some applications that are useful for banking.

Our primary use case of this solution is as an API gateway. We are customers of IBM and I'm a technology consultant.

It is the go-to solution for API repository products. We use it for runtime by designing certain products, and those products are subscribed to by various consuming systems.

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 solution is primarily used as the API gateway. It's for the application that performs the function as the API for the consumer.

Right now, our use cases are all internal. It's all API socialization internally. With version 10, we'd like to go externally with an actual API marketplace, however, we haven't gone there yet. I don't publish; I manage infrastructure. My role is to implement the infrastructure, maintain it, and enable the developers to leverage the technology.

We use this solution for external API spotters and API.

We use IBM API Connect before API publishing for enterprises. If we have a big enterprise and they want to publish their data for the public, we use API connect.

We are using this solution to handle our open API Connection. Our company mainly has cooperation with institutions, and we are hoping that with this product, in the future we can create easy connections to other institutions who also implement open API.

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.

Our primary use case for this product was doing a project for the banking industry. We had to use it to help comply with PSD2 (Payment Services Directive) regulations.

We use this solution for managing APIs.

The API manager of the enterprise exposes common functionalities to the front-end applications, beginning with the frontend of the executives who access clients' information. The exposition of the functionalities of transferring funds and AFP which need to transfer the money from your account to a client's AFP. The exposition of the core functionalities to the module of the sale of a product installed on the cloud of AWS, to create an onboarding platform for the client's prospect of the enterprise.

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.

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.

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.

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.

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

We primarily use the solution for distribution.

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

Building APIs.

This solution is primarily used for workflow applications. Specifically, it is used for web applications with complex workflows that have many users.