By apipark — 18 Feb 2026

Mastering Kuma-API-Forge: Simplified API Creation

kuma-api-forge

In the rapidly evolving landscape of modern software development, the humble Application Programming Interface (API) has transcended its traditional role to become the fundamental connective tissue of digital ecosystems. From microservices orchestrating complex business logic to external partners integrating their systems and mobile applications consuming backend data, APIs are at the very heart of how software interacts, shares information, and delivers value. However, the proliferation of APIs, while enabling unparalleled agility and scalability, simultaneously introduces a myriad of challenges: how to efficiently create, secure, manage, and expose these interfaces in a way that is both robust and developer-friendly? This question forms the crucible from which innovative solutions must emerge.

Traditional approaches to API management, often relying on standalone API Gateway products or custom-built proxies, have served their purpose. Yet, as architectures shift towards increasingly distributed microservices patterns, a more integrated, intelligent, and flexible approach is needed. This is where the concept of "Kuma-API-Forge" comes into play – a powerful conceptual framework leveraging the universal service mesh capabilities of Kuma to streamline the entire lifecycle of API creation and management. It's about taking the inherent strengths of a service mesh, designed for inter-service communication and policy enforcement, and extending them to the domain of external-facing APIs, simplifying what was once a complex, multi-layered endeavor.

This comprehensive guide will delve deep into the principles and practicalities of mastering Kuma-API-Forge. We will explore how Kuma, as an advanced control plane, can serve as the foundational layer for forging robust and scalable APIs. From defining clear OpenAPI specifications that act as the blueprint for our interfaces to leveraging Kuma's sophisticated traffic, security, and observability policies, we will unpack how to transform internal services into consumable APIs with unprecedented ease and control. Our journey will cover the evolving landscape of APIs, the core tenets of Kuma, practical implementation details for simplified API creation, advanced management scenarios, and the indispensable role of OpenAPI in ensuring consistency and quality. By the end, you will possess a profound understanding of how Kuma-API-Forge can empower your organization to accelerate API development, enhance security, and achieve operational excellence in the dynamic world of microservices.

The Evolving Landscape of APIs and Microservices: A Foundation for Kuma-API-Forge

The digital transformation sweeping across industries has fundamentally reshaped how applications are designed, built, and deployed. Gone are the days when monolithic applications, tightly coupled and challenging to update, dominated the enterprise landscape. The paradigm shift towards microservices architecture has ushered in an era of nimble, independently deployable services, each responsible for a specific business capability. This architectural revolution, while offering immense benefits in terms of agility, scalability, and technological diversity, simultaneously introduces a new set of complexities, particularly concerning inter-service communication and external exposure.

At the heart of the microservices paradigm lies the api. Each microservice, by definition, exposes its functionality through well-defined APIs, allowing other services to consume its capabilities without needing to understand its internal implementation details. This contract-first approach fosters loose coupling, enabling teams to develop, deploy, and scale services independently. However, as the number of microservices within an organization grows, managing the sheer volume of these internal APIs becomes a significant challenge. Service discovery, secure communication, reliable message delivery, and effective load balancing are critical concerns that can quickly overwhelm development and operations teams if not addressed systematically.

Furthermore, beyond internal communication, many of these microservices need to expose their capabilities to external consumers – mobile applications, web frontends, partner integrations, or third-party developers. This external exposure introduces an entirely new layer of requirements. External APIs demand robust security mechanisms, including authentication and authorization, rate limiting to prevent abuse, comprehensive analytics for monitoring usage, and clear, up-to-date documentation. Traditionally, these external-facing concerns have been managed by a dedicated API Gateway. An API Gateway acts as a single entry point for all client requests, routing them to the appropriate backend service, enforcing security policies, and often performing tasks like request transformation, caching, and analytics collection.

While standalone API Gateway solutions have proven effective, they often exist as a separate infrastructure layer, requiring their own deployment, configuration, and management. In a complex microservices environment already grappling with the intricacies of a service mesh for internal communication, adding another disparate layer can increase operational overhead and introduce inconsistencies in policy enforcement. This is precisely where the vision of Kuma-API-Forge emerges: to unify the control plane for both internal service-to-service communication and external api exposure, leveraging the same underlying service mesh technology.

The need for standardization in api definition has also become paramount. Without a universal language to describe the capabilities of an api, documentation becomes fragmented, client integration is arduous, and quality assurance is challenging. This is where OpenAPI (formerly Swagger) specifications come into play. OpenAPI provides a language-agnostic, human-readable, and machine-readable format for describing RESTful APIs. It acts as a contract between the API provider and consumer, detailing available endpoints, operations, parameters, authentication methods, and response models. An OpenAPI specification is not just documentation; it's a blueprint that can be used to generate client SDKs, server stubs, interactive documentation portals, and even drive automated testing and validation processes. Integrating OpenAPI as a central artifact within an API creation framework is therefore non-negotiable for modern development practices.

The confluence of microservices, the increasing demand for robust external APIs, the operational complexities of managing disparate systems, and the critical need for OpenAPI standardization sets the stage for a more integrated approach. Kuma, as a universal service mesh, offers the foundational elements to address these challenges head-on, creating a unified control plane that simplifies the creation, management, and governance of all APIs, whether internal or external. By extending Kuma's powerful policy engine to the api gateway function, we can achieve unparalleled consistency, efficiency, and security across the entire API landscape.

Understanding Kuma and its Core Principles: The Engine Behind Kuma-API-Forge

To truly master Kuma-API-Forge, one must first grasp the foundational power of Kuma itself. Kuma is an open-source, universal control plane for service meshes, designed to run on any platform – Kubernetes, VMs, or bare metal. It simplifies the complexities of networking, security, and observability in distributed environments, allowing developers to focus on writing business logic rather than grappling with infrastructure concerns. Kuma extends beyond the capabilities of traditional service meshes by offering a "universal" approach, meaning it can manage services across heterogeneous environments, providing a single pane of glass for operational control.

At its core, Kuma operates on a simple yet profound principle: centralize control, decentralize data plane enforcement. It achieves this through two main components:

The Control Plane: This is the brain of Kuma. It's where all the configuration and policies for the mesh are defined. Operators specify how services should communicate, what security policies apply, how traffic should be routed, and how observability data should be collected. The Kuma control plane then translates these high-level policies into concrete configurations for the data plane proxies. Being universal, Kuma's control plane can manage multiple meshes (each called a "Kuma mesh") across different clusters and environments, offering a truly global view and control mechanism. This centralized intelligence is key to simplifying API management, as it allows for consistent policy application across all exposed services.
The Data Plane: These are lightweight proxies (built on top of Envoy) that run alongside each service instance. Each data plane proxy intercepts all incoming and outgoing network traffic for its associated service. The control plane pushes configurations to these data plane proxies, instructing them on how to handle traffic based on the defined policies. This includes tasks like service discovery, load balancing, traffic routing, encryption (mTLS), authentication, authorization, and metrics collection. The data plane is responsible for enforcing the actual network policies in real-time, ensuring that services adhere to the rules set by the control plane. The intelligence is in the control plane, but the muscle is in the data plane proxies.

Kuma's strength lies in its declarative policy engine. Instead of manually configuring network rules for each service, operators define policies using custom resource definitions (CRDs) in Kubernetes or YAML files for VM deployments. These policies cover a wide array of service mesh functionalities:

Traffic Management: Kuma allows for sophisticated control over how traffic flows between services. This includes load balancing (round robin, least request, etc.), traffic routing (based on headers, paths, weights), retries, timeouts, and circuit breaking. These capabilities are directly applicable to api gateway functions, enabling fine-grained control over how external requests are directed to backend APIs.
Security: A paramount concern for any api, Kuma provides robust security features. It automates mutual TLS (mTLS) encryption for all service-to-service communication, ensuring that traffic within the mesh is always encrypted and authenticated. Kuma also supports TrafficPermission policies to define which services can talk to which, and MeshTrafficPermission to define permissions based on specific API paths or methods, providing an authorization layer.
Observability: Understanding the behavior of APIs is crucial for maintaining their health and performance. Kuma automatically collects metrics (Prometheus format), logs (via various log aggregators), and traces (Jaeger compatible) for all traffic flowing through the data plane proxies. This built-in observability reduces the need for application-level instrumentation, offering a consistent view of API performance and potential bottlenecks.

For Kuma-API-Forge, the universal nature of Kuma is particularly advantageous. Whether your backend services run on Kubernetes pods, traditional virtual machines, or even serverless functions, Kuma can bring them under a single, unified service mesh. This means that API management policies applied through Kuma's control plane will consistently govern all your services, regardless of their underlying infrastructure. This consistency dramatically simplifies operations, reduces the likelihood of misconfigurations, and ensures a uniform security posture across your entire API estate.

Furthermore, Kuma's architecture, being built on Envoy proxies, inherits Envoy's battle-tested performance and extensibility. This ensures that the data plane can handle high volumes of traffic with low latency, a critical requirement for any production-grade api gateway. The ability to configure these proxies declaratively through Kuma's control plane elevates API creation and management from a tedious, error-prone manual process to an automated, policy-driven operation. By understanding these core principles, we lay the groundwork for understanding how Kuma can be leveraged not just for internal service communication but as a powerful, integrated platform for exposing and managing external APIs with unprecedented simplicity and control.

Introducing Kuma-API-Forge: Bridging Service Mesh and API Management

The concept of "Kuma-API-Forge" represents a powerful convergence: taking the advanced capabilities of a service mesh like Kuma and extending them to the domain of external-facing api management. It's a methodological approach and a conceptual toolkit for leveraging Kuma as a highly intelligent and flexible API Gateway, simplifying the entire process of transforming internal services into robust, secure, and easily consumable APIs. Instead of viewing the service mesh and API Gateway as separate, often redundant, infrastructure layers, Kuma-API-Forge proposes a unified control plane that governs both internal service-to-service communication and external API exposure.

The "Forge" aspect implies a deliberate process of shaping and refining. With Kuma-API-Forge, we are forging raw internal service capabilities into polished, external-facing APIs. This involves:

Standardizing API Contracts: Utilizing OpenAPI specifications as the definitive blueprint for every API.
Intelligent Traffic Management: Directing external requests to the correct backend services using Kuma's advanced routing capabilities.
Comprehensive Security Enforcement: Applying authentication, authorization, and rate limiting policies directly within the mesh.
Integrated Observability: Gaining deep insights into API performance and usage patterns through Kuma's built-in monitoring and tracing.

The core idea is to use Kuma's MeshGateway resource (or similar Kuma ingress concepts) as the primary entry point for external API traffic. Unlike a traditional standalone API Gateway, which might require separate configuration and deployment, Kuma's MeshGateway is an integral part of the service mesh. It's essentially an Envoy proxy specifically configured by the Kuma control plane to handle ingress traffic into the mesh, applying all the mesh-level policies that are already defined for internal services. This means that an external api consumer's request enters the mesh through a MeshGateway data plane proxy, and from that point onwards, it is treated like any other request within the mesh, benefiting from mTLS, traffic policies, and observability.

How Kuma's Policies Streamline API Management

Kuma's declarative policy engine is the cornerstone of Kuma-API-Forge. Instead of writing complex API Gateway configurations, we define simple, human-readable policies that the Kuma control plane translates into granular instructions for the MeshGateway and subsequent data plane proxies:

Traffic Routing for APIs: Kuma's TrafficRoute policies enable sophisticated routing logic. For APIs, this means directing requests based on URL paths, HTTP headers, query parameters, or even specific methods (GET, POST, PUT, DELETE) to different backend services or different versions of the same service. For instance, /api/v1/users could be routed to users-service-v1, while /api/v2/users goes to users-service-v2. This greatly simplifies API versioning and phased rollouts.
Security at the API Gateway Level: Authentication and authorization are paramount for external APIs. While Kuma provides mTLS for internal service communication, external APIs often require JWT validation, OAuth2 flows, or API key authentication. Kuma's MeshGateway can be configured to integrate with external identity providers or perform token validation, securing the API entry point. Subsequently, TrafficPermission or MeshTrafficPermission policies can enforce granular authorization, determining which clients or identities can access specific API endpoints or resources.
Rate Limiting and Throttling: Preventing API abuse and ensuring fair usage is critical. Kuma's TrafficRateLimit policy allows you to define limits on the number of requests an api endpoint can receive within a given time frame, per client or per endpoint. This is directly equivalent to the rate limiting features found in dedicated API Gateway products, but managed consistently within the service mesh.
Resilience and Fault Tolerance: Kuma's policies for retries, timeouts, and circuit breaking enhance the resilience of exposed APIs. If a backend service becomes temporarily unavailable or slow, Kuma can automatically retry requests, implement timeouts to prevent cascading failures, or trip a circuit breaker to protect the backend from being overwhelmed, all transparently to the API consumer.

Benefits of the Kuma-API-Forge Approach

The unification offered by Kuma-API-Forge brings several compelling advantages:

Consistency: All API-related policies – traffic, security, observability – are managed through a single, consistent control plane. This eliminates the "policy gap" that often exists between a service mesh (for internal traffic) and a separate API Gateway (for external traffic).
Reduced Operational Overhead: By using Kuma for both internal and external API management, organizations can reduce the number of tools and infrastructure components they need to deploy and maintain. This simplifies operations, reduces configuration drift, and streamlines troubleshooting.
Enhanced Security: The pervasive mTLS provided by Kuma for internal mesh traffic, combined with explicit API authentication and authorization policies at the MeshGateway, creates a layered security model that is difficult to achieve with disparate systems.
Accelerated Development: Developers can focus on building service logic, knowing that the exposure, security, and traffic management of their APIs will be handled declaratively by the Kuma control plane, adhering to organizational standards.
Observability from Edge to Service: Kuma's built-in observability tools provide end-to-end visibility, from the moment an external request hits the MeshGateway to its propagation through various backend microservices.

Complementary Solutions: Extending Kuma-API-Forge with API Management Platforms

While Kuma-API-Forge provides an excellent foundation for simplified API creation and management within the service mesh, it's important to acknowledge that the broader api ecosystem often requires additional capabilities beyond traffic routing and policy enforcement. This is particularly true for complex enterprise environments or scenarios involving the rapid integration of AI models.

For instance, a comprehensive API management platform like APIPark can further streamline the external exposure and monetization of these APIs, offering features that complement a service mesh's primary focus. While Kuma excels at internal service communication and foundational API gateway functions like routing and security policies, platforms like APIPark provide crucial higher-level functionalities:

Developer Portal: A self-service portal for API consumers to discover, learn about, and subscribe to APIs, access documentation (often driven by OpenAPI specs), and manage their API keys.
Monetization & Billing: Features to meter API usage, set up pricing plans, and integrate with billing systems.
Unified AI Gateway: Specific capabilities for integrating and managing a multitude of AI models, standardizing invocation formats, and encapsulating prompts into REST APIs, which is a specialized need beyond typical service mesh functions.
Advanced Analytics & Reporting: More business-focused dashboards and reports on API usage, performance, and consumer behavior, distinct from raw infrastructure metrics.
End-to-End API Lifecycle Management: Tools to manage API versions, deprecation, and full governance across an API's entire lifespan, from design to retirement.

Therefore, Kuma-API-Forge can be seen as the robust, performant, and secure foundation for exposing services as APIs, deeply integrated into the infrastructure. For organizations requiring a full-fledged developer experience, advanced analytics, and specialized features like AI integration, complementing Kuma-API-Forge with a platform like APIPark can provide an unparalleled end-to-end solution for all API needs. The strength lies in recognizing that these tools are not mutually exclusive but rather synergistic, each addressing specific layers of the API management challenge.

Simplified API Creation with Kuma-API-Forge: Practical Aspects

Now that we understand the conceptual framework and the underlying power of Kuma, let's dive into the practical steps of simplified api creation using Kuma-API-Forge. This involves defining the API contract, exposing services through Kuma's MeshGateway, securing the endpoints, and ensuring robust observability.

1. Defining the API Contract: The Crucial Role of OpenAPI

Before exposing any service as an api, the first and most critical step is to define its contract. This contract dictates how consumers will interact with the API, what data they can send, and what responses they can expect. For RESTful APIs, OpenAPI (formerly Swagger) specifications have become the de facto standard.

An OpenAPI specification is a complete, language-agnostic description of your RESTful API. It covers:

Endpoints: The URLs available (e.g., /users, /products/{id}).
Operations: HTTP methods supported for each endpoint (GET, POST, PUT, DELETE).
Parameters: Inputs required for each operation (path parameters, query parameters, headers, request body).
Request/Response Bodies: Schemas for the data expected in requests and returned in responses, often defined using JSON Schema.
Authentication: Security schemes supported (API keys, OAuth2, JWT).
Metadata: API title, description, version, contact information.

Why is OpenAPI Crucial for Kuma-API-Forge?

Single Source of Truth: The OpenAPI spec becomes the authoritative blueprint for your API. Any discrepancy between the documentation and the actual implementation indicates an issue.
Enhanced Developer Experience: It allows for the generation of interactive documentation (like Swagger UI), making it easy for API consumers to understand and test the API without writing any code.
Automated Tooling: OpenAPI can drive automated client SDK generation, server stub generation, and API testing. This significantly accelerates development and integration.
Gateway Configuration Guidance: While Kuma primarily works with routing rules, the OpenAPI spec implicitly defines the paths and methods that the MeshGateway needs to expose, guiding the configuration of Kuma's traffic policies.
Validation: In advanced scenarios, an API Gateway can validate incoming requests against the OpenAPI schema, rejecting malformed requests before they even reach the backend service, improving security and stability.

Example OpenAPI Snippet:

openapi: 3.0.0
info:
  title: User Management API
  version: 1.0.0
  description: API for managing user profiles
servers:
  - url: http://api.example.com/v1
paths:
  /users:
    get:
      summary: Get all users
      operationId: getAllUsers
      responses:
        '200':
          description: A list of users
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/User'
    post:
      summary: Create a new user
      operationId: createUser
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/NewUser'
      responses:
        '201':
          description: User created successfully
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/User'
        '400':
          description: Invalid input
components:
  schemas:
    User:
      type: object
      properties:
        id:
          type: string
          format: uuid
          description: Unique identifier for the user
        name:
          type: string
        email:
          type: string
          format: email
    NewUser:
      type: object
      properties:
        name:
          type: string
        email:
          type: string
          format: email
      required:
        - name
        - email

Developers should commit their OpenAPI definitions to version control alongside their service code. Tools like Stoplight Studio, Swagger Editor, or even simple text editors can be used to create and manage these specifications.

2. Exposing Services as APIs via Kuma's MeshGateway

Once the OpenAPI contract is defined and the backend service is running within the Kuma mesh, the next step is to expose it through a Kuma MeshGateway. The MeshGateway acts as the entry point for external traffic into your mesh, leveraging Envoy proxy to handle incoming requests and apply Kuma's policies.

Deployment of a MeshGateway:

A MeshGateway is deployed like any other service in your infrastructure, but it's specifically configured by Kuma to act as an ingress. In Kubernetes, this would typically involve a Deployment for the MeshGateway proxy and a Service to expose it externally (e.g., via a LoadBalancer or NodePort). The Kuma MeshGateway custom resource then tells the Kuma control plane how to configure this proxy.

Example Kuma MeshGateway Resource (Kubernetes):

apiVersion: gateway.kuma.io/v1alpha1
kind: MeshGateway
metadata:
  name: api-gateway
  namespace: kuma-system # Or your designated gateway namespace
spec:
  selectors:
    - match:
        kuma.io/service: api-gateway-01_kuma-system # Matches the Kuma service name for the gateway deployment
  conf:
    listeners:
      - port: 8080
        protocol: HTTP
        tags:
          hostname: api.example.com

This MeshGateway resource defines a listener on port 8080 for HTTP traffic, associating it with a specific hostname. The selectors ensure that this configuration applies to the correct Envoy proxy instances that are part of your api-gateway-01 service.

Routing External API Requests with MeshGatewayRoute:

To map specific api paths to your internal services, you use a MeshGatewayRoute custom resource. This resource defines the actual routing logic from the MeshGateway to your backend services, aligning with your OpenAPI specification.

Example MeshGatewayRoute for the User API:

Assume you have an internal user-service running in the default namespace, exposed on port 80.

apiVersion: gateway.kuma.io/v1alpha1
kind: MeshGatewayRoute
metadata:
  name: user-api-route
  namespace: default # The namespace of the backend service
spec:
  mesh: default
  selectors:
    - match:
        kuma.io/service: api-gateway-01_kuma-system
  conf:
    http:
      rules:
        - matches:
            - path:
                match: PREFIX
                value: /v1/users # Matches /v1/users and any sub-paths
          filters: # Optional: add filters like request headers/body manipulation
            - type: RequestHeader
              requestHeader:
                name: X-Correlation-ID
                set: "generated-uuid" # Example: Add a correlation ID
          forwardTo:
            - port: 80
              # The Kuma service name for your internal user-service
              # Format: <service-name>_<namespace>
              destinations:
                - match:
                    kuma.io/service: user-service_default

This MeshGatewayRoute instructs the api-gateway-01 to forward any request starting with /v1/users to the user-service in the default namespace on port 80. You can define multiple rules within a single MeshGatewayRoute to handle different paths or methods for the same API, or create multiple MeshGatewayRoute resources for different APIs.

Key Routing Capabilities:

Path-based Routing: As shown above, matching based on PREFIX, EXACT, or REGEX.
Header-based Routing: Directing traffic based on HTTP headers (e.g., User-Agent, X-API-Version). This is particularly useful for A/B testing or canary releases.
Method-based Routing: Differentiating routes based on GET, POST, PUT, DELETE operations.
Weighted Routing: Splitting traffic between different versions of a service (e.g., 90% to v1, 10% to v2 for canary deployments).
Request/Response Transformation: Although not directly shown in basic MeshGatewayRoute, Envoy (and thus Kuma) can perform advanced transformations like adding/removing headers, rewriting paths, or even modifying body content via WASM extensions, if needed for complex api gateway patterns.

3. Security for Exposed APIs: Layered Protection

Security is non-negotiable for external APIs. Kuma-API-Forge allows you to implement a layered security model:

Authorization with TrafficPermission: Once authenticated, you need to authorize users/clients to access specific API resources. Kuma's TrafficPermission policies allow you to define fine-grained access control based on service tags or even specific HTTP methods and paths.Example TrafficPermission:yaml apiVersion: kuma.io/v1alpha1 kind: TrafficPermission metadata: name: allow-user-api-access namespace: default spec: mesh: default sources: - match: kuma.io/service: api-gateway-01_kuma-system # Only requests from the API Gateway # Potentially add tags based on authenticated user roles passed by gateway destinations: - match: kuma.io/service: user-service_default # To the user service kuma.io/protocol: http action: Allow This ensures that only requests originating from the api-gateway-01 service are permitted to reach the user-service. For more granular authorization based on user roles (extracted from JWTs by an external auth service and passed as headers), you might dynamically add tags to the MeshGateway traffic or use a policy engine like OPA (Open Policy Agent) integrated with Envoy.
Rate Limiting with TrafficRateLimit: To protect your APIs from being overwhelmed or abused, apply rate limiting.Example TrafficRateLimit for the User API:yaml apiVersion: kuma.io/v1alpha1 kind: TrafficRateLimit metadata: name: user-api-rate-limit namespace: default spec: mesh: default sources: - match: kuma.io/service: api-gateway-01_kuma-system # From the API Gateway destinations: - match: kuma.io/service: user-service_default # To the user service conf: http: requestRate: num: 100 # Allow 100 requests interval: 10s # per 10 seconds burst: 10 # Allow a burst of 10 requests above the rate onRateLimit: status: 429 # HTTP status code for rate limit exceeded headers: - name: X-RateLimit-Limit value: "100" - name: X-RateLimit-Remaining value: "0" - name: X-RateLimit-Reset value: "10" This policy limits requests to the user-service via the api-gateway-01 to 100 requests every 10 seconds, with a burst allowance of 10.

External Authentication at the MeshGateway: The MeshGateway can be configured to perform authentication before forwarding requests to backend services. This is often done by validating API keys, JSON Web Tokens (JWTs), or integrating with an OAuth2 provider. Kuma's MeshGateway supports external authentication services.Example (Conceptual Kuma configuration for external auth): While Kuma MeshGateway itself might not have built-in direct JWT validation, it can integrate with an external authentication service or leverage Envoy's rich filter chain capabilities. You could deploy an external-authz service within your mesh that validates tokens, and configure the MeshGateway to pass requests through this service using an ExternalService and TrafficRoute or specific MeshGatewayRoute filters.Alternatively, for direct JWT validation, you might use EnvoyFilter (a raw Envoy configuration capability if Kuma's CRDs don't directly expose this for MeshGateway):```yaml

This is a highly simplified and conceptual example for JWT validation using EnvoyFilter,

often requiring deeper understanding of Envoy. Kuma's CRDs might abstract this in the future.

apiVersion: kumactl.io/v1alpha1 kind: EnvoyFilter metadata: name: jwt-auth-filter namespace: kuma-system spec: mesh: default service: api-gateway-01_kuma-system listener: name: api-gateway-listener-8080 filterChain: filter: name: "envoy.filters.network.http_connection_manager" typedConfig: "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager httpFilters: - name: "envoy.filters.http.jwt_authn" typedConfig: "@type": type.googleapis.com/envoy.extensions.filters.http.jwt_authn.v3.JwtAuthentication providers: jwt_provider: issuer: "https://your-auth-server.com" audiences: ["your-api-audience"] jwksUri: "https://your-auth-server.com/.well-known/jwks.json" forward: true # Forward the JWT in request header rules: - match: prefix: /v1/users requires: providerName: jwt_provider - name: "envoy.filters.http.router" typedConfig: {} `` This conceptualEnvoyFilterwould apply a JWT authentication filter to requests targeting/v1/usersat theapi-gateway-01` listener.

4. Observability for APIs: See What's Happening

Understanding API usage and performance is vital. Kuma's built-in observability makes this straightforward:

Metrics (Prometheus & Grafana): Kuma automatically exposes Prometheus metrics from its data plane proxies (including the MeshGateway). You can scrape these metrics to monitor request rates, latencies, error rates, and resource utilization for all your APIs. A Grafana dashboard can then visualize these metrics, providing real-time insights into API health and performance.
Tracing (Jaeger): Kuma can integrate with distributed tracing systems like Jaeger or Zipkin. By enabling tracing, every request flowing through the mesh (from MeshGateway to backend services) generates trace spans, allowing you to visualize the entire request flow, identify bottlenecks, and pinpoint latency issues across multiple services.
Logging: Data plane proxies generate access logs detailing every request and response. These logs can be configured to be sent to a centralized logging solution (e.g., Elasticsearch, Loki) for analysis, troubleshooting, and auditing.

By combining the clarity of OpenAPI definitions with Kuma's robust MeshGateway for exposure, declarative policies for security and traffic management, and integrated observability, Kuma-API-Forge significantly simplifies the traditionally complex task of creating and managing APIs. It moves the focus from imperative, ad-hoc configurations to a policy-driven, infrastructure-agnostic approach, empowering development and operations teams alike.

APIPark is a high-performance AI gateway that allows you to securely access the most comprehensive LLM APIs globally on the APIPark platform, including OpenAI, Anthropic, Mistral, Llama2, Google Gemini, and more.Try APIPark now! 👇👇👇

Install APIPark – it’s free

Advanced API Management Scenarios with Kuma-API-Forge

Beyond basic API exposure, Kuma-API-Forge excels in handling advanced api management scenarios, leveraging Kuma's sophisticated policy engine to implement complex deployment strategies, ensure high availability, and enhance API resilience. These capabilities are crucial for organizations operating at scale, where continuous delivery, minimal downtime, and robust performance are paramount.

API Versioning: Graceful Evolution

API versioning is a common challenge as APIs evolve. Breaking changes require new versions, but seamless transitions are essential for consumers. Kuma-API-Forge, through MeshGatewayRoute and TrafficRoute policies, makes versioning straightforward:

Header-based Versioning: Consumers specify the desired API version in a custom HTTP header (e.g., X-API-Version: v2). This allows the same URL path to serve different versions. MeshGatewayRoute can use headers in its matches section:```yaml

Within a MeshGatewayRoute rule:

rules: - matches: - path: { match: PREFIX, value: /users } headers: - name: X-API-Version value: v2 match: EXACT forwardTo: - port: 80 destinations: - match: { kuma.io/service: user-service-v2_default } ```

URL Path Versioning: The most common approach, where the version is embedded in the URL (e.g., /v1/users, /v2/users). A MeshGatewayRoute can easily direct requests based on the path prefix to the corresponding service version.```yaml apiVersion: gateway.kuma.io/v1alpha1 kind: MeshGatewayRoute metadata: name: user-api-v1-route namespace: default spec: mesh: default selectors: - match: kuma.io/service: api-gateway-01_kuma-system conf: http: rules: - matches: - path: { match: PREFIX, value: /v1/users } forwardTo: - port: 80 destinations: - match: { kuma.io/service: user-service-v1_default }

apiVersion: gateway.kuma.io/v1alpha1 kind: MeshGatewayRoute metadata: name: user-api-v2-route namespace: default spec: mesh: default selectors: - match: kuma.io/service: api-gateway-01_kuma-system conf: http: rules: - matches: - path: { match: PREFIX, value: /v2/users } forwardTo: - port: 80 destinations: - match: { kuma.io/service: user-service-v2_default } ```

This flexibility ensures that you can manage multiple API versions concurrently, allowing consumers to migrate at their own pace while maintaining backward compatibility where necessary.

Blue/Green Deployments and Canary Releases for APIs

For safer API updates, minimizing risk and downtime is critical. Kuma-API-Forge facilitates advanced deployment strategies:

Blue/Green Deployments: Deploy a new version (Green) alongside the old (Blue). Once the Green version is validated, Kuma's MeshGatewayRoute or TrafficRoute can instantly switch all traffic from Blue to Green. If issues arise, a quick rollback involves switching traffic back to Blue. This provides zero-downtime deployments.
Canary Releases: Gradually roll out a new API version to a small subset of users (e.g., 5% of traffic) for real-world testing. Kuma's TrafficRoute with weighted destinations is perfect for this.yaml apiVersion: kuma.io/v1alpha1 kind: TrafficRoute metadata: name: user-service-canary namespace: default spec: mesh: default sources: - match: kuma.io/service: api-gateway-01_kuma-system destinations: - match: kuma.io/service: user-service_default # This is the "target" service for the route conf: split: - weight: 95 destination: kuma.io/service: user-service-v1_default # Old version - weight: 5 destination: kuma.io/service: user-service-v2_default # New canary version This TrafficRoute splits traffic for the logical user-service (as seen by the gateway) between user-service-v1 and user-service-v2. As confidence in v2 grows, you can gradually increase its weight until it handles 100% of the traffic, then deprecate v1.

Fault Injection and Resilience Testing

To ensure APIs are resilient under adverse conditions, Kuma allows for fault injection, simulating failures within the mesh. This is crucial for proactive testing of an api's ability to handle network delays, failed requests, or service unavailability.

Delay Injection: Simulate network latency or slow backend services.
Abort Injection: Simulate HTTP error responses (e.g., 500, 503) or TCP connection failures.

apiVersion: kuma.io/v1alpha1
kind: FaultInjection
metadata:
  name: user-service-delay-injection
  namespace: default
spec:
  mesh: default
  sources:
    - match:
        kuma.io/service: api-gateway-01_kuma-system
  destinations:
    - match:
        kuma.io/service: user-service_default
  conf:
    delay:
      percentage: 50 # 50% of requests will experience a delay
      value: 5s # delay of 5 seconds

This policy injects a 5-second delay into 50% of requests from the api-gateway-01 to the user-service. This allows you to test how your API consumers (and api gateway configurations like timeouts) react to slow responses without actually breaking the backend service.

Multi-Cluster API Management

One of Kuma's strongest features is its "universal" nature, allowing it to manage services and policies across multiple clusters (e.g., Kubernetes clusters in different regions) or hybrid environments (Kubernetes and VMs). For APIs, this means:

Global API Gateway: A single logical api gateway managed by Kuma can span multiple physical clusters, providing unified access to services deployed across geographically dispersed environments.
Disaster Recovery: API traffic can be seamlessly failed over to a different cluster if a primary region experiences an outage, enhancing the availability of your APIs.
Geo-distributed APIs: Route API requests to the nearest available service instance based on the consumer's location, reducing latency. Kuma's ZoneIngress and ZoneEgress mechanisms enable secure and efficient cross-cluster communication, making it possible to treat services across your entire infrastructure as a single, cohesive unit for API management.

Comparison: Kuma-API-Forge vs. Traditional API Gateway

To further highlight the distinct advantages and complementary aspects, let's look at a comparative table.

Feature / Aspect	Traditional API Gateway (e.g., Nginx, Kong, Apigee)	Kuma-API-Forge (Kuma MeshGateway + Policies)
Deployment Model	Separate deployment/infrastructure layer.	Integrated into the service mesh. `MeshGateway` is another Envoy proxy managed by Kuma.
Control Plane	Dedicated control plane for API gateway.	Unified Kuma control plane for both internal mesh and external API management.
Traffic Management	Routes to specific services, load balancing, path rewriting.	Routes to services, load balancing (mesh-aware), path rewriting, advanced traffic splitting (canary, A/B).
Security	Authentication (JWT, OAuth, API keys), Authorization, WAF.	External Auth integration, internal mTLS, `TrafficPermission`, `MeshTrafficPermission`.
Rate Limiting	Policy-based rate limiting per consumer/endpoint.	`TrafficRateLimit` policy, consistent with internal service rate limits.
Observability	Logs, metrics, sometimes integrated tracing.	Built-in, consistent metrics (Prometheus), tracing (Jaeger), and logs across all services.
Policy Consistency	Policies defined separately from internal service mesh policies.	Consistent policy definition and enforcement for all traffic (internal & external).
API Lifecycle	Often includes developer portal, monetization, versioning, documentation.	Focus on traffic, security, and observability for API exposure. Versioning via routing.
AI Integration	Varies, typically through custom plugins or backend integrations.	Core Kuma doesn't focus on this, but can route to AI services. (APIPark excels here as a complement).
Operational Complexity	Manage `API Gateway` + Service Mesh (if applicable) as two distinct systems.	Single control plane for both, reducing operational overhead.
Best Suited For	Full-featured API Management, Monetization, Large-scale external dev experience.	Microservices-native API exposure, unified control, internal-external policy consistency, performance.

This table illustrates that while a traditional API Gateway often provides a broader set of features for the entire API lifecycle (especially for external-facing developer experience and monetization), Kuma-API-Forge offers a more integrated, streamlined, and operationally efficient approach for the core functions of exposing, securing, and routing APIs within a service mesh environment. In many cases, the two can be complementary, with Kuma-API-Forge handling the raw ingress and policy enforcement, and a platform like APIPark building on top of that for developer portals, AI integration, and business-centric analytics.

The Role of OpenAPI in the Kuma-API-Forge Ecosystem

The OpenAPI specification is not merely a documentation format; it is the foundational contract that underpins the entire Kuma-API-Forge ecosystem. In a world increasingly dominated by distributed systems and autonomous teams, clear, machine-readable API contracts are indispensable. They serve as the shared understanding between API providers and consumers, facilitating efficient integration, reducing errors, and accelerating development cycles.

OpenAPI as the "Source of Truth" for APIs

In the Kuma-API-Forge paradigm, the OpenAPI definition for each api should be treated as its single, immutable source of truth. This means:

Design-First Approach: APIs are designed and documented using OpenAPI before implementation begins. This encourages thoughtful API design, ensuring consistency, usability, and adherence to best practices.
Version Control: OpenAPI files should be version-controlled alongside the API's source code. Any changes to the API's contract must be reflected and reviewed in the OpenAPI specification.
Automated Validation: Tools can compare the deployed API's behavior against its OpenAPI specification, flagging any discrepancies. This ensures that the implementation consistently matches the documented contract.

By adopting this approach, the OpenAPI specification becomes more than just a reference; it becomes a living blueprint that guides development, testing, and deployment.

Driving Automated Tooling and Workflows

The machine-readable nature of OpenAPI unlocks a wealth of automation opportunities within Kuma-API-Forge:

Interactive Documentation: Tools like Swagger UI or Redoc can parse an OpenAPI file and automatically generate beautiful, interactive documentation portals. These portals allow developers to explore API endpoints, understand parameters, view response schemas, and even make test calls directly from their browser. This significantly improves the developer experience for API consumers.
Client SDK Generation: Many tools can automatically generate client-side code (SDKs) in various programming languages (e.g., Java, Python, JavaScript) directly from an OpenAPI specification. This eliminates the tedious and error-prone process of manually writing api client code, allowing consumers to integrate with the API much faster.
Server Stub Generation: Similarly, OpenAPI can be used to generate server-side boilerplate code (stubs) for API implementations. This ensures that the server-side implementation adheres to the defined contract from the outset.
Automated Testing: OpenAPI specifications can be used to generate comprehensive API test suites. Tools can create test cases for valid requests, invalid parameters, authentication failures, and various response scenarios, ensuring that the API behaves as expected. This is particularly valuable for regression testing when new API versions are deployed.
API Gateway Configuration (Indirectly): While Kuma's MeshGatewayRoute resources are defined directly, the OpenAPI specification informs what paths, methods, and parameters need to be routed and potentially validated. In more advanced scenarios (or with external API management platforms), OpenAPI could directly generate or validate API Gateway configurations.
Schema Validation: As mentioned earlier, an API Gateway can be configured to validate incoming request bodies and query parameters against the OpenAPI schema. This acts as a robust first line of defense, rejecting malformed requests before they even reach the backend services, thereby improving security and reducing the load on upstream applications.

Integration with Developer Portals

For external APIs, providing a rich developer experience is crucial for adoption. A well-designed developer portal, often a feature of comprehensive API management platforms like APIPark, leverages OpenAPI specifications to offer:

Centralized API Catalog: A single place for developers to discover all available APIs.
Interactive Documentation: As described above, generated directly from OpenAPI.
API Key Management: Allowing developers to generate and manage their credentials.
Usage Analytics: Providing insights into how their applications are consuming the APIs.
Subscription Workflows: Enabling controlled access to APIs, potentially requiring administrator approval.

APIPark's capabilities to manage OpenAPI definitions, present them in a user-friendly developer portal, and even encapsulate prompts into REST APIs based on custom logic, perfectly complement Kuma's role in the underlying traffic and policy enforcement. Kuma-API-Forge ensures the api is robustly exposed, while a platform like APIPark ensures it's easily discoverable, consumable, and governable for a broader audience.

In essence, OpenAPI serves as the universal language for APIs within the Kuma-API-Forge ecosystem. It transforms API creation from an ad-hoc process into a structured, contract-driven methodology that empowers developers, ensures consistency, and significantly enhances the overall quality and usability of your APIs, from internal service interaction to external developer consumption.

Best Practices and Considerations for Kuma-API-Forge

Implementing Kuma-API-Forge effectively requires adherence to best practices and careful consideration of several operational aspects. While Kuma simplifies many complexities, a thoughtful approach ensures stability, security, and scalability for your APIs.

1. API Design Principles

RESTful Consistency: Adhere to established REST principles (resource-oriented, stateless, standard HTTP methods). This makes APIs intuitive and predictable for consumers.
Clear Naming Conventions: Use consistent and descriptive names for resources, parameters, and endpoints.
Versioning Strategy: Plan your API versioning strategy early (e.g., URL path, header-based) and communicate it clearly in your OpenAPI documentation.
Meaningful Responses: Provide clear HTTP status codes and informative error messages (e.g., using problem details RFC 7807) to help consumers diagnose issues.
Pagination & Filtering: For collection resources, implement pagination, filtering, and sorting to prevent large data transfers and improve efficiency.
Idempotency: For non-GET operations (POST, PUT, DELETE), consider how to make them idempotent where appropriate, allowing safe retries.

2. Security Hardening

Least Privilege: Configure TrafficPermission policies to allow only the necessary communication between your MeshGateway and backend services, and between services themselves.
Authentication & Authorization:
- For external APIs, always require authentication (JWT, OAuth2, API Keys) at the MeshGateway layer.
- Implement granular authorization (e.g., role-based access control - RBAC) at the service level, potentially using external authorization services integrated with Kuma/Envoy filters, or leveraging the identity passed through from the gateway.
Data Encryption in Transit: Kuma's mTLS ensures all internal service-to-service communication is encrypted. Ensure external API communication to the MeshGateway uses HTTPS/TLS.
Input Validation: Validate all incoming API request data against your OpenAPI schemas. While Kuma focuses on routing, you can integrate schema validation filters into your MeshGateway (e.g., via Envoy filters or a dedicated validation service).
Rate Limiting: Aggressively apply TrafficRateLimit policies to protect your APIs from denial-of-service attacks and ensure fair usage.
Security Scanning: Regularly scan your API code and infrastructure for vulnerabilities.

3. Performance Optimization

Efficient Backend Services: Ensure your microservices themselves are performant, as the MeshGateway primarily routes traffic and enforces policies.
Load Balancing: Leverage Kuma's advanced load balancing algorithms (e.g., least request, consistent hashing) to distribute API traffic efficiently across backend instances.
Caching: Consider implementing caching for frequently accessed, non-volatile data, either at the MeshGateway level (if supported or via custom Envoy filters) or within your backend services.
Resource Allocation: Ensure your MeshGateway proxy and backend service instances are allocated sufficient CPU and memory resources to handle anticipated API traffic volumes. Kuma's performance rivals Nginx, capable of achieving over 20,000 TPS with an 8-core CPU and 8GB memory, especially when deployed in a cluster to handle large-scale traffic. This highlights its capability to manage high-throughput API environments.

4. Operational Considerations

Monitoring and Alerting: Set up comprehensive monitoring of API metrics (latency, error rates, request volume) from Kuma's Prometheus integration. Configure alerts for deviations from baseline performance or security thresholds.
Logging: Centralize and analyze API access logs and application logs. Ensure logs provide sufficient detail for troubleshooting without exposing sensitive information. APIPark, for example, offers detailed API call logging, recording every detail for quick tracing and troubleshooting, which is a valuable addition to standard mesh logging.
Tracing: Use distributed tracing (Jaeger) to quickly diagnose performance bottlenecks and understand the end-to-end flow of API requests across multiple services.
GitOps for Policies: Manage all Kuma policies (MeshGateway, MeshGatewayRoute, TrafficPermission, TrafficRateLimit, etc.) using GitOps principles. Store them in a Git repository, and use automated pipelines for deployment, ensuring version control, auditability, and consistent deployments.
Test Thoroughly: Implement comprehensive automated tests for your APIs, including unit tests, integration tests, and end-to-end tests that interact with the MeshGateway. Use Kuma's fault injection to test resilience.
Documentation Management: Maintain accurate and up-to-date OpenAPI specifications. Consider using tools that automatically publish or synchronize these specs with a developer portal.

5. Team Collaboration and Governance

Shared Understanding: Foster a shared understanding across development, operations, and security teams about how Kuma-API-Forge works and how APIs are managed.
API Governance: Establish clear guidelines and standards for API design, security, and operations. This includes defining conventions for OpenAPI specifications and Kuma policies.
Centralized API Discovery: For large organizations, beyond what Kuma offers, a dedicated API developer portal (like that provided by APIPark) is crucial for centralizing API discovery, documentation, and access management. This allows different departments and teams to easily find and use the required api services. APIPark also supports independent API and access permissions for each tenant, enabling multi-team collaboration with strong isolation. Moreover, API resource access often requires approval, preventing unauthorized calls and potential data breaches, which is an important governance feature.

By diligently applying these best practices, organizations can fully leverage the power of Kuma-API-Forge to create, manage, and scale their APIs with confidence, ensuring they are not only performant and secure but also easy to consume and operate in dynamic microservices environments.

Conclusion

The journey through Mastering Kuma-API-Forge reveals a transformative approach to api creation and management in the modern era of microservices. We've seen how the proliferation of APIs, while driving innovation and agility, also introduced a complex web of challenges related to communication, security, and governance. Traditional API Gateway solutions have played their part, but the advent of universal service meshes like Kuma offers a more integrated and consistent pathway forward.

Kuma-API-Forge stands as a powerful conceptual framework that marries the robust capabilities of Kuma's service mesh with the critical requirements of external api exposure. By leveraging Kuma's universal control plane, we can establish a unified policy enforcement point for both internal service-to-service communication and external api access. This eliminates operational silos, reduces complexity, and ensures a consistent security posture across the entire distributed system. We delved into how Kuma's MeshGateway and its declarative policies for traffic routing, security, and rate limiting simplify the traditionally arduous tasks of exposing and protecting APIs.

Central to this simplification is the indispensable role of OpenAPI specifications. These machine-readable contracts serve as the definitive blueprint for every api, driving automated documentation, client generation, and robust validation, thereby ensuring consistency and accelerating integration for API consumers. We also explored advanced scenarios, demonstrating Kuma-API-Forge's prowess in handling api versioning, enabling safe blue/green and canary deployments, facilitating resilience testing through fault injection, and managing APIs across heterogeneous multi-cluster environments.

The power of Kuma-API-Forge lies in its ability to empower development and operations teams. Developers can focus on building business logic, confident that the underlying infrastructure, governed by Kuma, will handle the complexities of api exposure, security, and reliability. Operations teams benefit from a unified control plane, simplified policy management, and comprehensive observability from the edge to the deepest service. While Kuma provides the robust foundation for these core api gateway functions, complementary platforms like APIPark further enhance the developer experience with features like comprehensive developer portals, specialized AI model integration, and advanced business analytics, building a complete end-to-end API management ecosystem.

Mastering Kuma-API-Forge is not merely about adopting a new tool; it's about embracing a paradigm shift towards intelligent, policy-driven API governance. It's about forging a future where api creation is no longer a bottleneck but a seamless, integrated process that accelerates innovation, enhances security, and ultimately drives the success of digital initiatives in an increasingly interconnected world.

5 Frequently Asked Questions (FAQs)

1. What is Kuma-API-Forge and how does it differ from a traditional API Gateway?

Kuma-API-Forge is a conceptual framework that leverages the Kuma universal service mesh to manage and expose external APIs. Unlike a traditional API Gateway which is often a separate infrastructure component with its own control plane, Kuma-API-Forge integrates the API Gateway functionality directly into the service mesh via Kuma's MeshGateway and policy engine. This means a single Kuma control plane governs both internal service-to-service communication and external API traffic, offering consistent policy enforcement, reduced operational overhead, and built-in observability from the mesh.

2. How does OpenAPI fit into the Kuma-API-Forge workflow?

OpenAPI (formerly Swagger) specifications are crucial for Kuma-API-Forge. They serve as the definitive contract for your APIs, describing endpoints, operations, parameters, and responses in a machine-readable format. In the Kuma-API-Forge workflow, the OpenAPI spec guides the design and implementation of the API, informs the configuration of Kuma's MeshGatewayRoute policies (defining paths and methods to expose), and drives automated tooling like interactive documentation generation, client SDKs, and API testing. It ensures consistency, clarity, and accelerates development for both API providers and consumers.

3. Can Kuma-API-Forge handle advanced API management features like API versioning and canary releases?

Yes, Kuma-API-Forge excels at advanced API management scenarios. For API versioning, Kuma's MeshGatewayRoute policies can direct traffic based on URL paths (e.g., /v1/users vs. /v2/users) or HTTP headers, allowing multiple API versions to coexist. For canary releases and blue/green deployments, Kuma's TrafficRoute policies enable sophisticated weighted traffic splitting, gradually shifting traffic to new API versions while monitoring performance, or instantly switching between environments with zero downtime. Kuma's fault injection capabilities also allow for robust resilience testing.

4. How does Kuma-API-Forge ensure API security?

Kuma-API-Forge implements a layered security model. For internal service communication, Kuma provides automated mutual TLS (mTLS) encryption and authentication. For external APIs, the MeshGateway can be configured to integrate with external authentication services (e.g., for JWT or OAuth2 validation) or apply API key validation. TrafficPermission and MeshTrafficPermission policies enforce granular authorization, controlling which clients can access specific API endpoints. Additionally, TrafficRateLimit policies protect against API abuse and denial-of-service attacks. The unified control plane ensures consistent security enforcement across your entire API landscape.

5. Is Kuma-API-Forge a complete API Management platform on its own, or does it need complementary tools?

Kuma-API-Forge provides a robust, performant, and secure foundation for exposing services as APIs, deeply integrated into your service mesh infrastructure. It handles core API Gateway functionalities like routing, traffic management, security, and observability exceptionally well. However, for a complete end-to-end API Management solution, particularly for external-facing APIs, it often benefits from complementary tools. Platforms like APIPark can augment Kuma-API-Forge by providing a comprehensive developer portal, API monetization features, advanced business analytics, and specialized capabilities such as unified AI model integration and prompt encapsulation into REST APIs, which go beyond the primary focus of a service mesh. Together, they create a powerful and holistic API ecosystem.

🚀You can securely and efficiently call the OpenAI API on APIPark in just two steps:

Step 1: Deploy the APIPark AI gateway in 5 minutes.

APIPark is developed based on Golang, offering strong product performance and low development and maintenance costs. You can deploy APIPark with a single command line.

curl -sSO https://download.apipark.com/install/quick-start.sh; bash quick-start.sh

In my experience, you can see the successful deployment interface within 5 to 10 minutes. Then, you can log in to APIPark using your account.

Step 2: Call the OpenAI API.