We mainly use these APIs for east-to-west communication within our internal system and partner collaboration. While most companies prefer tool-based API management for partner collaboration, for internal consumption, and integration between application insight, we tend to use cloud-native tools provided by AWS.

We primarily use it for real-time use cases where we have used Lambda with the API Gateway. So, the backend is a Lambda server. We are implementing a serverless architecture with the API Gateway. 

We've implemented risk score models within the Lambda. Thus, whenever someone requires a risk assessment for a prospect in need of a loan, they access our Amazon API Gateway. In the backend, it triggers the Lambda service.

So, within the Lambda, our ML model predicts whether the customer falls into the high-risk or low-risk category. Then, it sends a response to our frontend application, which is an Android-based application.

Currently, our use cases are relatively simple. Even though we host ten different models, the use cases are similar. We have configured the API gateway for various URLs and receive hits from different services like tractors, two-wheelers, and mobiles. 

We primarily use the solution as an API gateway. The APIs are managed by serverless applications. It's an API gateway from Layer 7.

I use the solution in my company to develop AWS Lambda services. My company uses Amazon API Gateway to expose AWS Lambda functions and explore our APIs. I use the product to manage microservices.

We use Amazon API Gateway for some solutions we have integrated with ServiceNow. Some operations need to be done with the help of Amazon API Gateway. If API Gateway's path is available, we can easily integrate it with other solutions.

We use Amazon API Gateway to expose some APIs. I worked for three companies that mostly used API Gateway for exposed services and complex use cases like expose headers. The solution is used to personalize responses, provide more simulations, and facilitate communication between the services. The solution is also used to direct some requests to Lambda and ECS.

All of my APIs and microservices are behind the Amazon API Gateway. When someone sends a request to the API Gateway, it performs validation and then forwards it to the appropriate microservice. Several microservices, such as payment services, deposit services, and account services, are all behind the API Gateway.

We use the solution as a gateway between the front-end and the back-end. It helps us setup proper authentication and provides a neat and easily configurable view of our application's public interface.

So we are using Amazon API Gateway in our application. It allows us to expose our APIs and provides tools for managing them.

I use the solution for API management. I use Amazon API Gateway for SQL Server Stretch Database.

Our clients have specific use cases. They require a gateway that performs well and can handle around three hundred requests per quarter.

The gateway is the first layer of protection. When traffic comes in, we need to complete a couple of validation steps such as adding a rate limit. We then scan documents for viruses and upload them. All information and data needs to be sanitized before it enters a private domain and we use this solution to do this.

I've primarily used the solution to call Lambda functions and embrace new features that they introduce. My role doesn't require me to explore the full range of API Gateway features, but rather simpler ones like repair gateway functions as and when required. Additionally, in relation to AWS Step Functions, there are key distinctions between instant and long-life step functions that should be highlighted. It isn’t very transparent and useful for me. Instant step functions are suitable for tasks that can be completed within around ten minutes, whereas long-lived ones can endure for extended periods by saving their states between steps.

I use it to expose API. So, I primarily use it for publishing our APIs and implementing rate limiting.

We mainly use it within our internal services.

We are integrating the Amazon API Gateway for one of our projects in phase four. We also use our built-in agent assist system to connect the customer to the backend. It handles and processes API calls for the application's responses.

We primarily utilize Amazon API Gateway to expose our APIs externally and enhance security by implementing components such as input validation, filtering, and ensuring secure exposure through the gateway.

Our use case is we have some internal APIs that we need to expose to the outside world. Via API Gateway, we expose those APIs to the external world.

When you have multiple API applications, Amazon API Gateway can serve as both your front end and your middleware. When you have microservices, for example, you can run Amazon API Gateway with Kubernetes. It can also build out the requests.

We also have the serverless application being hosted in Lambda. Lambda is an AWS resource that we use Amazon API Gateway with when we have received a request. It redirects the traffic to that particular request.

I use the solution in my company for microservices architecture. I have five years of experience with Amazon and Tenable. I see many services offered by Amazon.

We put the APIs behind an API gateway. Before the users hit the API, they must go through the Amazon API Gateway. We can control how people use our APIs. We use the tool to manage the entire API process.

We integrated Amazon API Gateway with their microservices architecture using GitHub and Java.

We use Amazon API Gateway to expose our back end to the front end.

I use AWS API Management and Mulesoft because I work on different solutions and I am in a different layer, because I most focused on backend solutions. I have participated in some projects using these tools but I am not a developer or an expert.

We have designed and implemented RESTful API's. For example, based on Microservices with Spring Boot and AKS or OpenShift.

We use Amazon API Gateway to compliment or to put a security facade on top of your current APIs.

I use this solution for mobile app development. It is the API gateway for my backend.

We're using Amazon API Gateway for API management.

We use it for normal API purposes.

We use the solution to protect APIs from malicious attacks.

We primarily use this solution for exposing internal data sources to the internet.

We use an API from Amazon to assess our internal services in our VPC and to limit the access of certain users to API and to have an execution plan. Certain users have certain access to API calls that they could use to give them an assessed quota.

The solution is deployed on a private cloud.

We use it for API routing and managing traffic. These are managed authentications between the API and back to primary users. 

Our primary use case is a fully serverless architecture for the application.

We primarily use the solution for providing controlled access to our services running within Amazon.

We are currently using this solution in a project that we are implementing for a public service organization. It is a content management system that will be able to do things like rate monitoring. The service will have good security and availability.

This is a cloud-based deployment with Lambda Integration.