How to Test a MuleSoft Proxy: A Comprehensive Guide

In the rapidly evolving landscape of digital transformation, Application Programming Interfaces (APIs) have emerged as the fundamental building blocks of modern software ecosystems. They facilitate seamless communication between diverse applications, enabling enterprises to innovate faster, connect services, and extend their digital reach. However, the sheer volume and complexity of API interactions necessitate robust management and protection mechanisms. This is where an api gateway truly shines, acting as a crucial intermediary that governs how external and internal consumers interact with backend services. Among the leading solutions in this domain, MuleSoft stands out, offering powerful capabilities for API management, integration, and orchestration. Within the MuleSoft ecosystem, the concept of a MuleSoft Proxy is particularly significant, providing a layer of abstraction and control over backend APIs.

A MuleSoft Proxy, in essence, is a dedicated api gateway that sits in front of your actual backend services. It acts as the public-facing endpoint, handling requests before they ever reach the underlying implementation. This strategic placement allows organizations to enforce a wide array of policies – ranging from security and throttling to routing and analytics – without modifying the backend service itself. The ability to abstract and control access to APIs is paramount for maintaining system stability, ensuring data integrity, and optimizing performance. Yet, the very benefits that proxies offer introduce new layers of complexity that demand rigorous and methodical testing.

The objective of this comprehensive guide is to delve deep into the critical aspects of testing a MuleSoft Proxy. We will explore why thorough testing is not merely a best practice but an absolute necessity for enterprise-grade API deployments. From understanding the core components and functionalities of a MuleSoft Proxy to dissecting various types of testing – functional, performance, and security – we will equip you with the knowledge and strategies required to build resilient and reliable API architectures. By the end of this article, you will have a clear roadmap for designing, implementing, and executing an effective testing strategy that ensures your MuleSoft Proxies, and by extension your entire api infrastructure, operate flawlessly under all conditions.

Understanding MuleSoft Proxies: The Frontline of Your API Ecosystem

At its core, a MuleSoft Proxy serves as a sophisticated intermediary, a specialized api gateway designed to enhance, secure, and manage access to your backend APIs. It's not just a simple passthrough; it's a dynamic layer where policies are applied, traffic is managed, and insights are gathered before a request ever touches the actual service implementation. This strategic positioning is what makes a MuleSoft Proxy an indispensable component in any modern enterprise integration architecture, especially when dealing with a multitude of services and diverse consumer bases.

What Exactly is a MuleSoft Proxy?

A MuleSoft Proxy is a distinct Mule application, typically deployed on MuleSoft's Anypoint Platform or on-premise, that acts as a facade for a target API. Instead of clients directly invoking your backend api, they interact with the proxy. This proxy then forwards the request to the backend service after applying a set of predefined rules and policies. The architecture usually involves:

1. Backend API: The actual service providing the business logic and data (e.g., a REST service, SOAP service, database connector, or another Mule application).
2. MuleSoft Proxy Application: A lightweight Mule application that receives incoming requests, applies policies managed through Anypoint API Manager, and then routes the processed request to the backend api.
3. Anypoint API Manager: The control plane within Anypoint Platform where API definitions are published, and policies are configured and applied to the proxy. This separation of concerns means that the api owner can manage security, throttling, and other aspects without needing to directly modify the backend code.

Unlike direct API deployments where the api implementation is exposed, a proxy decouples the consumer's view of the api from its actual implementation details. This abstraction layer is powerful, allowing for greater flexibility and control over the API lifecycle.

Why Utilize a MuleSoft Proxy? The Multifaceted Benefits

The deployment of a MuleSoft Proxy is driven by a compelling array of business and technical advantages that significantly enhance the overall api ecosystem. These benefits are critical for any organization striving for robust, secure, and scalable api management.

1. Enhanced Security and Policy Enforcement

One of the primary reasons to deploy a proxy is to fortify api security. MuleSoft Proxies enable the enforcement of a wide range of security policies managed centrally through Anypoint API Manager. This includes:

• Client ID Enforcement: Mandating that all incoming requests include a valid client ID and client secret, ensuring only authorized applications can access the api.
• OAuth 2.0 and JWT Validation: Integrating with identity providers to secure apis through industry-standard token-based authentication and authorization mechanisms. The proxy can validate tokens, scopes, and expiration dates.
• IP Whitelisting/Blacklisting: Controlling access based on source IP addresses, preventing unauthorized network access.
• Threat Protection: Implementing policies to detect and mitigate common api threats like SQL injection, XML external entities (XXE), and JSON schema validation, thereby protecting backend services from malicious payloads.
• CORS Policies: Managing Cross-Origin Resource Sharing to control which web applications can make requests to your api.

By centralizing policy enforcement at the gateway level, you ensure consistent security across all proxied APIs, reduce the burden on backend developers, and create a strong defensive perimeter.

2. Advanced Traffic Management and Quality of Service

MuleSoft Proxies provide granular control over api traffic, ensuring fair usage, preventing overload, and maintaining optimal performance. Key traffic management capabilities include:

• Rate Limiting and Throttling: Limiting the number of requests an application or user can make within a specified timeframe. This prevents individual consumers from monopolizing api resources and protects backend services from being overwhelmed. Policies can be applied globally or on a per-client basis.
• Spike Arrest: Managing sudden, unexpected bursts of traffic that could otherwise crash backend services. Spike arrest policies smooth out traffic peaks, allowing the api to gracefully handle temporary surges.
• SLA-based Policies: Defining different service level agreements for various consumers (e.g., premium clients get higher rate limits), allowing for tiered access and monetization strategies.
• Caching: Proxies can cache api responses, reducing the load on backend systems and significantly improving response times for frequently requested data.

These features are crucial for maintaining the stability and performance of your apis, especially under varying load conditions.

3. Flexible Routing and Transformation

MuleSoft Proxies offer powerful capabilities to manipulate requests and responses as they traverse the gateway, providing flexibility without altering backend code:

• URL Rewriting and Path-based Routing: Changing the incoming URL path to match the backend service's expected endpoint, allowing for cleaner, more user-friendly external api URLs.
• Header and Query Parameter Manipulation: Adding, removing, or modifying headers and query parameters in both request and response flows. This can be used for injecting security tokens, tracking information, or adapting to backend requirements.
• Content-Based Routing: Directing requests to different backend services based on the content of the request payload, enabling sophisticated routing logic.
• Data Transformation: While complex transformations are typically handled by integration applications, proxies can perform simple JSON/XML transformations or apply templates to modify request/response bodies.

This flexibility allows api consumers to interact with a consistent interface, even if the backend services undergo changes or have specific, perhaps less-than-ideal, interface requirements.

4. Enhanced Observability and Analytics

Positioning a proxy as the single entry point for api traffic provides a centralized point for monitoring, logging, and analytics.

• Centralized Logging: All api requests and responses passing through the proxy can be logged, providing a comprehensive audit trail and aiding in troubleshooting.
• Real-time Monitoring: Anypoint Platform provides dashboards and alerts to monitor api performance, policy violations, and error rates in real-time, allowing proactive issue detection.
• Traffic Analytics: Gaining insights into api usage patterns, top consumers, most accessed endpoints, and performance trends. This data is invaluable for capacity planning, api improvement, and business intelligence.

This comprehensive visibility is crucial for understanding how your APIs are being consumed and for ensuring their continuous health and optimal operation.

5. Decoupling and Versioning

A proxy layer effectively decouples api consumers from the underlying backend implementation. This means:

• Backend Changes Without Consumer Impact: If a backend service needs to be refactored, moved, or even replaced, the proxy can be reconfigured to point to the new service without api consumers needing to update their integrations, provided the external api contract remains consistent.
• API Versioning: Proxies can facilitate api versioning strategies (e.g., URL-based, header-based), allowing multiple versions of an api to coexist while providing a clean way for consumers to select their desired version. This enables smooth transitions and deprecation processes.

By providing this robust layer of abstraction, MuleSoft Proxies significantly simplify api management, reduce maintenance overhead, and accelerate the development lifecycle. They are a cornerstone for building resilient, scalable, and secure api ecosystems.

The Indispensable Role of Comprehensive Testing for MuleSoft Proxies

The decision to deploy a MuleSoft Proxy is a strategic one, aimed at enhancing security, performance, and manageability of your API ecosystem. However, the very benefits that a proxy introduces also create new critical points of failure and complexity that demand an exhaustive testing regimen. Neglecting comprehensive testing of your MuleSoft Proxies is akin to building a state-of-the-art security system and forgetting to test if the locks actually work. The potential repercussions, ranging from minor inconveniences to catastrophic system failures and severe data breaches, underscore why testing is not just a good idea, but an absolute necessity.

Business Impact of Untested Proxies

The ripple effects of an inadequately tested MuleSoft Proxy can extend far beyond technical glitches, impacting an organization's bottom line, reputation, and competitive standing.

1. Customer Dissatisfaction and Revenue Loss

If proxy policies, routing, or performance are not thoroughly vetted, customers or partner applications consuming your APIs will experience issues. This could manifest as slow response times, unexpected errors, denied access, or even complete service outages. Such failures directly translate to a degraded user experience, leading to frustration, loss of trust, and ultimately, churn. For APIs that underpin critical business processes or revenue-generating applications (e.g., e-commerce, payment gateways), even brief outages can result in significant financial losses.

2. Data Breaches and Compliance Violations

The proxy is the frontline for enforcing security policies. If these policies (e.g., OAuth validation, IP whitelisting, threat protection) are misconfigured or fail to operate as expected, your backend services become vulnerable. A security lapse at the proxy level can lead to unauthorized data access, data breaches, or denial-of-service attacks. Such incidents not only incur severe financial penalties and legal liabilities (especially concerning regulations like GDPR, HIPAA, or PCI DSS) but also inflict irreparable damage to brand reputation. Demonstrating due diligence through rigorous security testing of the api gateway is often a regulatory requirement.

3. Reputational Damage and Loss of Trust

In today's interconnected world, news of api outages or security vulnerabilities spreads rapidly. A reputation for unreliable or insecure APIs can deter potential partners, drive away existing customers, and undermine the perception of your organization's technical competence. Rebuilding trust after such incidents is a long and arduous process, often costing more than the investment in preventative testing.

4. Operational Inefficiencies and Increased Costs

When proxies fail in production, operations teams face immense pressure to identify and resolve issues quickly. This often involves lengthy troubleshooting sessions, emergency patches, and potential resource diversions from other critical projects. The operational overhead associated with managing and fixing production incidents caused by untested proxy configurations can significantly escalate operational costs and reduce overall team productivity.

Technical Impact of Untested Proxies

Beyond the business ramifications, the technical implications of skipping proxy testing are equally profound, directly impacting the stability, security, and performance of your api infrastructure.

1. Unexpected Behavior and Functionality Failures

The core function of a proxy is to apply policies and route requests. If functional tests are not conducted thoroughly, a policy intended to allow specific access might inadvertently block legitimate requests, or conversely, a security policy might fail to block malicious ones. Routing logic might direct requests to the wrong backend service, leading to incorrect data processing or errors. Even subtle configuration errors can lead to unpredictable behavior that is difficult to diagnose in a live environment.

2. Performance Bottlenecks and Scalability Issues

Proxies, by their nature, add a small amount of latency to each request. While usually negligible, misconfigurations, inefficient policy chaining, or improper resource allocation for the proxy application itself can turn it into a significant performance bottleneck. Without performance testing (load, stress, spike testing), organizations risk deploying proxies that cannot handle expected traffic volumes, leading to slow response times, timeouts, and eventual service unavailability under load. Scalability issues might not manifest until peak times, making them even harder to troubleshoot.

3. Security Vulnerabilities and Exploitable Gaps

A proxy is often the first line of defense for your APIs. If its security policies are not comprehensively tested against various attack vectors – including edge cases and negative scenarios – vulnerabilities can go undetected. This could involve an unvalidated token allowing unauthorized access, a rate-limiting policy that is easily bypassed, or a threat protection policy that fails to sanitize malicious input. These gaps represent direct entry points for attackers.

4. Inefficient Resource Utilization

An incorrectly configured or underperforming proxy can consume excessive CPU, memory, or network resources on the server where it's deployed. This not only impacts the proxy's own performance but can also starve other critical applications running on the same infrastructure, leading to broader system instability. Performance testing helps to right-size resources and optimize configurations.

5. Integration Breakdowns

APIs rarely operate in isolation. They are part of complex integration flows. A faulty proxy can disrupt these flows, causing cascading failures across interconnected systems. For example, if a proxy incorrectly transforms a request or response, a downstream service might receive malformed data, leading to its own processing errors.

The "Shift Left" Imperative

Recognizing these profound impacts, the modern software development paradigm advocates for "shifting left" – integrating testing activities as early as possible in the development lifecycle. For MuleSoft Proxies, this means:

• Designing for Testability: Architecting proxies with clear, modular policies that are easy to isolate and test.
• Unit Testing: While proxies themselves don't have traditional unit tests in the same way a Mule application does, the underlying logic or any custom policies developed should be unit tested.
• Early Policy Validation: Testing policy configurations as soon as they are defined in Anypoint API Manager, even before full deployment.
• Automated Testing in CI/CD: Incorporating automated functional, performance, and security tests into the continuous integration and continuous delivery (CI/CD) pipeline. This ensures that every change to the proxy configuration or related api is immediately validated, catching issues before they reach production.

In conclusion, a MuleSoft Proxy is a powerful gateway component, but its effectiveness is entirely dependent on its correctness and resilience. Comprehensive testing is not an optional extra; it is a fundamental pillar for ensuring the security, reliability, performance, and overall success of your enterprise api strategy. Without it, you are exposed to significant risks that can undermine your entire digital architecture.

Types of Testing for MuleSoft Proxies: A Multi-Faceted Approach

Effectively testing a MuleSoft Proxy requires a multi-faceted approach, encompassing various testing types to validate its functionality, performance, and security posture. Each type of testing addresses different aspects of the gateway's behavior, collectively ensuring a robust and reliable api management layer.

1. Functional Testing: Validating Policy Enforcement and Routing Logic

Functional testing is perhaps the most fundamental type of testing for a MuleSoft Proxy. Its primary goal is to verify that the proxy behaves exactly as intended, correctly applying policies and routing requests to the appropriate backend services. This involves testing both the "happy path" (expected successful scenarios) and various "unhappy paths" (error conditions, invalid inputs, policy violations).

1.1 Policy Enforcement Testing

This is crucial because the proxy's main value proposition lies in its ability to enforce policies. Each policy applied to the proxy must be rigorously tested.

• Client ID Enforcement:
  • Valid Credentials: Send a request with a correct client_id and client_secret (usually in headers). Verify that the request is successfully forwarded to the backend.
  • Missing Credentials: Send a request without the required client_id or client_secret. Verify that the proxy rejects the request with a 401 Unauthorized or 400 Bad Request status code and a relevant error message.
  • Invalid Credentials: Send a request with incorrect or expired client_id/client_secret. Verify rejection with an appropriate error.
  • Blocked Client: Test with credentials of a client that has been intentionally blocked or revoked.
• Rate Limiting/Throttling:
  • Below Limit: Send requests below the defined rate limit within the time window. All requests should succeed.
  • At Limit: Send exactly the number of requests allowed. All should succeed.
  • Exceeding Limit: Send requests that exceed the limit within the time window. The excess requests should be rejected with a 429 Too Many Requests status code and an informative error.
  • Reset After Window: Verify that after the time window elapses, new requests are accepted again.
  • SLA Tiers: If different tiers are defined, test each tier to ensure its specific rate limits are correctly applied.
• Security Policies (OAuth 2.0, JWT Validation, IP Whitelisting):
  • Valid Token/IP: Send a request with a correctly formatted, unexpired token and valid scope, or from a whitelisted IP. Expect success.
  • Missing/Malformed Token: Send requests with no token, an improperly formatted token, or a token with missing claims. Expect rejection.
  • Expired Token: Use an expired token. Expect rejection.
  • Invalid Scope/Audience: Test tokens that do not have the required scopes or audience for the specific API resource. Expect rejection.
  • Non-Whitelisted IP: Attempt to access from an IP address not in the whitelist. Expect rejection.
  • Threat Protection: Send requests with known malicious patterns (e.g., SQL injection strings in parameters, large XML/JSON payloads, deeply nested structures for XXE attacks). Verify that the proxy correctly identifies and blocks these threats without forwarding them to the backend.
• Caching Policies:
  • First Request: Send a request and measure the response time.
  • Subsequent Requests (Cached): Send the same request immediately after. Expect a faster response time, indicating the response was served from cache.
  • Cache Expiration: Wait for the cache expiration period to pass, then send the request again. Expect a slower response as it hits the backend, then subsequent requests from cache again.

1.2 Routing Logic Testing

Verifying that requests are directed to the correct backend service and that any modifications to the request path or parameters occur as expected.

• URL Rewriting: If the proxy rewrites the incoming URL to a different backend path, verify that the backend receives the request at the rewritten path, not the original.
• Path-Based Routing: If different paths on the proxy lead to different backend services, ensure each path correctly invokes its designated backend.
• Content-Based Routing: For complex scenarios where the routing decision depends on the request body content (e.g., XML element value, JSON field), send requests with different payloads and verify that each is routed to the correct backend service.
• Header/Query Parameter Manipulation: If the proxy adds, removes, or modifies headers or query parameters, inspect the request received by the backend service to confirm these changes are applied correctly. Similarly, verify response header manipulation.

1.3 Error Handling Testing

Proxies are responsible for gracefully handling errors, both from upstream (client requests) and downstream (backend services).

• Invalid Requests: Send requests with malformed JSON/XML, incorrect HTTP methods, or missing required body parameters. Verify the proxy returns appropriate 4xx status codes (e.g., 400 Bad Request, 405 Method Not Allowed) and clear error messages.
• Backend Unavailability: Simulate a scenario where the backend service is down or unreachable. Verify the proxy returns a 50x status code (e.g., 503 Service Unavailable, 504 Gateway Timeout) and potentially a custom error page or message.
• Custom Error Responses: If the proxy is configured to return custom error payloads or redirect on certain error conditions, verify these customizations are working.

1.4 Data Transformation Testing

While full-scale transformations are often in a dedicated integration layer, proxies can perform light transformations.

• Request/Response Body Transformation: If the proxy is configured to transform the request body before sending it to the backend (e.g., from XML to JSON) or the response body before sending it to the client, verify the transformed payload matches the expected structure and content.
• Header/Query Parameter Transformation: Confirm that any value transformations in headers or query parameters (e.g., encrypting a value, reformatting a date) are executed correctly.

2. Performance Testing: Assessing Scalability and Responsiveness

Performance testing is crucial to ensure that the MuleSoft Proxy can handle the anticipated load without degrading service quality. It helps identify bottlenecks, confirm scalability, and validate the efficiency of deployed policies.

• Load Testing:
  • Objective: Simulate the expected average and peak user load over a sustained period.
  • Methodology: Gradually increase the number of concurrent virtual users or requests per second, measuring key metrics like response time, throughput (requests per second), and error rates.
  • Insights: Confirm that the proxy maintains acceptable response times and throughput under normal operating conditions. Identify potential performance regressions from new policy deployments.
• Stress Testing:
  • Objective: Push the proxy beyond its normal operating capacity to identify its breaking point and how it behaves under extreme load.
  • Methodology: Continuously increase the load until the proxy or its underlying infrastructure shows signs of failure (e.g., high error rates, timeouts, resource exhaustion).
  • Insights: Determine the maximum capacity of the proxy and its resilience. Understand how the system recovers after being stressed. This is vital for capacity planning.
• Spike Testing:
  • Objective: Test the proxy's ability to handle sudden, massive surges in traffic over a short period.
  • Methodology: Apply a sudden, significant increase in load, then drop it back to a normal level, observing the system's reaction.
  • Insights: Assess if spike arrest policies are effective and if the proxy can gracefully handle and recover from sudden traffic bursts without prolonged service degradation.
• Endurance Testing (Soak Testing):
  • Objective: Sustain a moderate to high load over an extended period (e.g., several hours, a full day).
  • Methodology: Run a consistent load for a long duration, monitoring resource consumption and performance metrics.
  • Insights: Detect potential memory leaks, resource exhaustion, or other performance degradations that only manifest over time. Ensure the proxy remains stable and performs consistently over long operational periods.

Key Metrics for Performance Testing: * Response Time: Average, median, 90th/95th/99th percentile response times. * Throughput: Requests per second (RPS). * Error Rate: Percentage of failed requests. * Resource Utilization: CPU, memory, network I/O of the proxy's runtime environment. * Latency: Time taken for a request to pass through the proxy.

3. Security Testing: Identifying Vulnerabilities and Exploitation Risks

Security testing for a MuleSoft Proxy is paramount, as it acts as the primary defense mechanism for your backend APIs. This type of testing aims to uncover vulnerabilities and ensure that implemented security policies are robust and cannot be bypassed.

• Authentication and Authorization Testing:
  • Bypass Attempts: Try to access protected api resources without providing any authentication credentials (e.g., client ID, OAuth token).
  • Weak Credentials/Tokens: Attempt to use easily guessable credentials or tokens that have weak encryption or short lifespans.
  • Token Manipulation: Modify valid tokens (e.g., change user ID, roles, scope, expiration) and try to access resources that should be restricted.
  • Role-Based Access Control (RBAC): If the proxy enforces RBAC based on token claims, ensure users with different roles can only access authorized resources.
• Input Validation and Threat Protection Testing:
  • Injection Attacks: Attempt SQL injection, OS command injection, or cross-site scripting (XSS) by embedding malicious code in URL parameters, headers, or request bodies. Verify the proxy correctly sanitizes or blocks these attempts.
  • Malformed Inputs: Send intentionally malformed JSON or XML payloads to test if the proxy's parsing and validation mechanisms are resilient and don't expose vulnerabilities.
  • Large Payloads/Denial of Service (DoS): Send extremely large payloads or a flood of small requests to test the proxy's ability to handle them without crashing or becoming unresponsive, ensuring policies like message size limits are effective.
• Penetration Testing:
  • Ethical Hacking: Engage security professionals to simulate real-world attacks against the proxy and its exposed APIs.
  • Vulnerability Scanning: Use automated tools to scan the proxy's endpoints for known vulnerabilities (e.g., using OWASP ZAP, Burp Suite).
  • Configuration Review: Manually review the proxy's configuration and deployed policies for best practices and potential misconfigurations.
• Error Message Disclosure: Ensure that error messages returned by the proxy do not leak sensitive information (e.g., internal stack traces, database schema details) that could aid an attacker.

4. Regression Testing: Maintaining Stability Over Time

Regression testing ensures that new changes, updates, or bug fixes to the proxy configuration, policies, or underlying platform do not inadvertently introduce new defects or reintroduce old ones.

• Automated Test Suites: The most effective approach is to maintain a comprehensive suite of automated functional, performance, and security tests.
• Triggering Regression: These suites should be run whenever there's a change to the proxy, a new api version, or an update to the Anypoint Platform runtime.
• Fast Feedback: Automated regression tests provide rapid feedback, allowing development teams to quickly identify and rectify issues, promoting a "fail fast" mentality.

By systematically applying these diverse testing methodologies, organizations can build confidence in the reliability, performance, and security of their MuleSoft Proxies, transforming them from mere traffic directors into robust, intelligent api gateways.

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! 👇👇👇

Tools and Strategies for Testing MuleSoft Proxies

Testing MuleSoft Proxies efficiently and effectively requires the right set of tools and a well-defined strategy. From manual inspection to sophisticated automated pipelines, the approach should be layered and integrated into the broader software development lifecycle.

1. Manual Testing Tools: Quick Checks and Exploratory Testing

While automation is paramount for comprehensive testing, manual tools remain invaluable for initial development, quick sanity checks, and exploratory testing.

• Postman:
  • Capabilities: A widely used API client that allows users to send HTTP requests, inspect responses, organize requests into collections, define environments (e.g., dev, staging, prod endpoints), and even write basic pre-request scripts and post-response assertion tests.
  • MuleSoft Proxy Use: Excellent for validating individual policy enforcements (e.g., sending a request with/without a Client ID to test enforcement), checking routing logic, and quickly verifying response structures. Its ability to manage environments simplifies switching between different proxy deployments.
  • Benefit: Low barrier to entry, highly visual, and supports team collaboration through workspace sharing.
• Insomnia:
  • Capabilities: Similar to Postman, offering a user-friendly interface for building, sending, and inspecting HTTP requests. It also supports environments, test suites, and powerful data templating.
  • MuleSoft Proxy Use: Provides an alternative to Postman with a strong focus on developer experience. Good for functional testing of policies and routing.
  • Benefit: Often preferred by developers for its clean UI and local data storage options.
• Curl:
  • Capabilities: A command-line tool for transferring data with URLs. It supports a wide range of protocols, including HTTP/HTTPS, and allows for precise control over request headers, methods, and body.
  • MuleSoft Proxy Use: Ideal for quick, repeatable command-line checks, especially in scripting or automated build environments where a full GUI tool isn't practical. Useful for basic reachability tests, header validation, and testing simple policy rejections.
  • Benefit: Lightweight, ubiquitous, and scriptable.

2. Automated API Testing Frameworks: The Backbone of Robust Testing

For comprehensive, repeatable, and scalable testing, automation is non-negotiable. These frameworks allow for the creation of sophisticated test suites that can be integrated into CI/CD pipelines.

• MUnit (for underlying Mule applications):
  • Context: While MUnit is primarily for testing Mule applications directly (e.g., the backend service or a custom policy implementation if it's part of a Mule app deployed as a proxy), it's important to understand its role. If your proxy includes custom Mule flow logic, MUnit is the tool for unit testing those specific components before they are deployed and proxied.
  • Benefit: Native to MuleSoft, offering deep integration with Mule applications.
• ReadyAPI (formerly SoapUI NG):
  • Capabilities: A comprehensive API testing platform from SmartBear that supports functional, load, and security testing of REST, SOAP, and other API types. It offers a rich GUI for test creation and robust reporting.
  • MuleSoft Proxy Use: Excellent for creating end-to-end functional test suites for proxies, including data-driven testing, assertions for various status codes and response bodies, and validation of policy enforcement. Its performance testing module is suitable for load and stress testing. The security testing module can perform scans for common vulnerabilities.
  • Benefit: All-in-one solution, strong enterprise features, and good for complex test scenarios.
• Newman (Postman CLI):
  • Capabilities: A command-line collection runner for Postman. It allows users to run Postman collections (which include requests and test scripts) from the command line.
  • MuleSoft Proxy Use: If your team is already heavily invested in Postman for manual testing, Newman provides a straightforward path to automate those collections. This is particularly useful for regression testing proxy policies and basic functional validation in a CI/CD environment.
  • Benefit: Leverages existing Postman assets, easy to integrate into CI/CD scripts.
• JMeter:
  • Capabilities: An open-source, Java-based tool from Apache, primarily used for load and performance testing. It can also be used for functional testing of APIs.
  • MuleSoft Proxy Use: Highly effective for performance testing (load, stress, spike, endurance) of MuleSoft Proxies. It can simulate a large number of concurrent users and collect detailed performance metrics. With proper configuration, it can also validate functional aspects by asserting response data.
  • Benefit: Highly customizable, extensible, and widely adopted in the industry for performance testing.
• Gatling:
  • Capabilities: An open-source load testing tool written in Scala, known for its high performance and developer-friendly DSL (Domain Specific Language) for defining test scenarios.
  • MuleSoft Proxy Use: An excellent choice for performance testing MuleSoft Proxies, especially in environments where developers prefer a code-centric approach. Its reporting is also highly detailed and visually appealing.
  • Benefit: Fast, efficient, and provides great reports.
• Karate DSL:
  • Capabilities: An open-source API test automation framework that supports testing REST and SOAP APIs, as well as UI and performance testing. It uses a BDD (Behavior-Driven Development) style syntax that is easy to read and write.
  • MuleSoft Proxy Use: Very effective for functional and regression testing of proxy policies and routing. Its native support for assertions and data manipulation makes it powerful for validating complex api gateway behaviors. It also has a performance testing extension.
  • Benefit: Simple syntax, powerful capabilities, and supports multiple types of testing from a single framework.

3. CI/CD Integration: Automating the Feedback Loop

The true power of automated testing for MuleSoft Proxies is realized when integrated into a Continuous Integration/Continuous Delivery (CI/CD) pipeline.

• Continuous Integration: Every time a change is committed to the proxy's configuration or a related api definition, the CI pipeline should automatically build (if necessary) and run a suite of automated functional and regression tests against a dedicated test environment.
  • Tools: Jenkins, GitLab CI, Azure DevOps, GitHub Actions, CircleCI.
  • Process: On commit, trigger a job that fetches the latest proxy configuration, deploys it to a test environment (or reconfigures an existing one), and then executes the automated test suite (e.g., Newman, ReadyAPI tests, Karate tests).
• Continuous Delivery: If all automated tests pass, the pipeline can then automatically deploy the proxy to a staging environment for further, perhaps more extensive, performance or security testing, or even to production with appropriate approvals.
• Gateways: Implement quality gates in the pipeline. If any critical test fails (e.g., a security policy bypass, a critical functional regression), the build should fail, preventing the deployment of faulty proxy configurations.

4. Monitoring and Observability (Post-Deployment): The Continuous Watch

Testing doesn't end once the proxy is in production. Continuous monitoring provides real-time insights into its health, performance, and security posture. This is where the concept of an api gateway truly extends beyond mere traffic management.

• Anypoint Monitoring: MuleSoft's native monitoring solution provides real-time dashboards, custom alerts, and detailed metrics for deployed applications, including proxies. It helps visualize api calls, identify performance bottlenecks, and track policy violations.
• External APM Tools (e.g., Splunk, Dynatrace, New Relic, Grafana): Integrating proxy logs and metrics with broader Application Performance Monitoring (APM) tools or log aggregation systems provides a unified view across your entire IT landscape. This allows for correlation of proxy performance with backend service performance and overall system health.
• Synthetic Monitoring: Deploying external monitors that periodically make calls to your proxied APIs to ensure they are always available and performing within acceptable SLAs.

For those looking for comprehensive api gateway solutions that go beyond just proxying to include AI integration, detailed logging, and powerful data analysis, platforms like APIPark offer an open-source, high-performance alternative. APIPark provides full api lifecycle management, robust monitoring capabilities, and unified API formats for diverse services, which can complement MuleSoft's offerings, especially in diverse enterprise environments requiring advanced AI gateway features. This broader scope of API management ensures that not only are your proxies robustly tested, but your entire api landscape is optimized for security, performance, and innovation.

Table: Comparison of Testing Tools for MuleSoft Proxies

Tool / Framework	Primary Use Case	Strengths	Weaknesses	Integration with CI/CD	Best Suited For
Postman	Functional (Manual/Scripted)	Ease of use, collections, environments, basic tests	Limited load testing, manual effort for complex scenarios	Via Newman	Initial dev, quick checks, exploratory, small teams
Insomnia	Functional (Manual/Scripted)	Clean UI, GraphQL support, robust templating	Similar limitations as Postman for automation/load	Limited direct	Developers preferring a lightweight, modern client
Curl	Basic Functional (Scripted)	Lightweight, ubiquitous, highly scriptable	Verbose, less intuitive for complex payloads	Easy	Command-line scripting, basic health checks
ReadyAPI	Functional, Load, Security	All-in-one suite, enterprise features, GUI, data-driven	Commercial license, steeper learning curve	Good	Comprehensive enterprise testing, complex scenarios
Newman	Automated Functional (CLI)	Automates Postman collections, lightweight	Relies on Postman for test creation	Excellent	Automating existing Postman tests in pipelines
JMeter	Load, Performance, Functional	Highly customizable, robust for load testing	Steeper learning curve, less intuitive for functional tests	Good	High-volume load/stress testing, performance benchmarks
Gatling	Load, Performance	High performance, code-centric DSL, detailed reports	Requires Scala/JVM familiarity, less GUI-driven	Excellent	High-performance load testing, developer-centric
Karate DSL	Functional, Performance, UI	BDD syntax, powerful for API testing, simple assertions	Relatively newer, less mature ecosystem than others	Excellent	Fast API test automation, BDD-style functional tests

Choosing the right tools and implementing a structured strategy will transform your MuleSoft Proxy testing from a reactive chore into a proactive quality assurance process, safeguarding your APIs and the critical business functions they enable.

Developing a Robust Testing Strategy for MuleSoft Proxies

Building a robust testing strategy for MuleSoft Proxies is not just about choosing tools; it's about defining a systematic approach that ensures all critical aspects of the proxy are validated throughout its lifecycle. A well-articulated strategy ensures efficiency, coverage, and ultimately, the reliability of your api gateway.

1. Define Clear Test Scope and Objectives

Before diving into execution, clarify precisely what needs to be tested and what success looks like.

• Identify Proxied APIs: List all backend APIs that the MuleSoft Proxy is fronting.
• Catalog Policies: Document every policy applied to the proxy (e.g., Client ID enforcement, Rate Limiting, OAuth, URL Rewriting, Threat Protection). For each, specify its expected behavior, configuration parameters, and the desired outcome for both valid and invalid scenarios.
• Define Routing Rules: Clearly outline all routing logic, including URL rewriting rules, path-based routing, and any content-based routing decisions.
• Set Performance Baselines: Establish acceptable thresholds for key performance indicators (KPIs) such as average response time, peak throughput, and error rates under different load conditions. These will be your targets for performance testing.
• Security Requirements: Articulate specific security requirements, such as compliance with OWASP Top 10, data encryption standards, and authentication protocols.

By defining these upfront, you create a clear scope, avoid ambiguity, and ensure that your testing efforts are focused on critical areas.

2. Prepare Comprehensive Test Data

The quality and variety of your test data are crucial for uncovering edge cases and validating diverse scenarios.

• Positive Test Data: Data representing valid inputs that should lead to successful api calls and expected policy enforcements.
• Negative Test Data: Data designed to trigger error conditions or policy violations. This includes:
  • Missing or malformed required fields.
  • Invalid authentication credentials (expired tokens, incorrect client IDs).
  • Requests that exceed rate limits.
  • Malicious payloads (e.g., SQL injection strings, XSS scripts) for security testing.
  • Edge cases: Boundary values (e.g., minimum/maximum allowed length for a string, zero values, largest possible numbers).
• Test Data Management: Implement a system to manage test data. This could involve using data files (CSV, JSON), dedicated test data generation tools, or integrating with mock services that provide specific data for testing. Ensure test data is anonymized or synthetic, especially for production-like environments, to protect sensitive information.

3. Choose the Right Tools for the Job

As discussed in the previous section, a range of tools exists for different testing types. Your strategy should outline which tools will be used for what purpose.

• Functional Testing: Postman/Insomnia for manual/exploratory, Newman/Karate DSL/ReadyAPI for automation.
• Performance Testing: JMeter/Gatling/ReadyAPI for load, stress, spike, and endurance tests.
• Security Testing: ReadyAPI, OWASP ZAP, Burp Suite, or dedicated penetration testing services.
• CI/CD Integration: Standard CI/CD platforms (Jenkins, GitLab CI, Azure DevOps) to orchestrate automated tests.

The selection should consider team expertise, existing tooling, budget constraints, and the specific needs of the proxy.

4. Prioritize Automation and Integrate into SDLC

Automation is the cornerstone of an efficient and sustainable testing strategy.

• Automate Everything Possible: Focus on automating functional, regression, and performance tests. Manual testing should be reserved for exploratory testing or scenarios that are genuinely difficult to automate.
• Shift-Left Approach: Integrate testing activities as early as possible in the Software Development Life Cycle (SDLC).
  • Development Phase: Developers should perform unit-level testing on any custom logic within the proxy.
  • Configuration Phase: As soon as policies are configured in Anypoint API Manager, automated tests should validate their immediate effect.
  • CI/CD Pipelines: Embed automated test suites into your CI/CD pipelines. Every code commit or configuration change to the proxy should trigger a comprehensive set of tests.
  • Test Environments: Have dedicated test environments (dev, QA, staging) that closely mirror production, allowing for isolated and consistent testing.
• Quality Gates: Implement "quality gates" in your CI/CD pipeline. If tests fail at a certain stage, the pipeline should halt, preventing faulty configurations from progressing to subsequent environments.

5. Simulate Real-World Scenarios

Effective testing goes beyond verifying individual policies; it involves simulating how the proxy will behave under realistic conditions.

• Network Latency: Introduce simulated network latency to assess how the proxy performs under less-than-ideal network conditions.
• Backend Failures: Simulate backend service outages, slow responses, or error conditions to test the proxy's error handling, circuit breaking (if implemented), and fallback mechanisms.
• Concurrency: Test how the proxy handles multiple concurrent requests, ensuring thread safety and resource contention are managed gracefully.
• Mixed Traffic: Simulate a mix of different api calls, some valid, some invalid, some exceeding limits, to mimic real-world traffic patterns.

6. Establish Clear Reporting and Analysis

Testing is only valuable if its results are clearly communicated and acted upon.

• Comprehensive Reports: Generate detailed reports for all test runs, including pass/fail status, performance metrics (response times, throughput), error rates, and any security vulnerabilities identified.
• Actionable Insights: Translate test results into actionable insights. For example, if performance tests reveal a bottleneck, pinpoint the specific policy or configuration causing the degradation.
• Dashboarding: Utilize dashboards (e.g., Anypoint Monitoring, Grafana) to visualize trends over time, track performance against baselines, and quickly identify any regressions.
• Bug Tracking Integration: Integrate test automation frameworks with your bug tracking system (e.g., Jira). Failed tests should automatically create or update bug tickets, streamlining the defect management process.

By diligently following these steps, organizations can establish a robust testing strategy that not only validates the functionality and performance of their MuleSoft Proxies but also proactively identifies and mitigates risks, ensuring the continuous health and reliability of their crucial api gateway layer. This strategic approach is fundamental to building a resilient and secure api ecosystem capable of supporting evolving business demands.

Best Practices for Testing MuleSoft Proxies

Beyond a solid strategy, adopting certain best practices can significantly enhance the effectiveness, efficiency, and maintainability of your MuleSoft Proxy testing efforts. These practices embody lessons learned from countless API deployments and help to foster a culture of quality within your development and operations teams.

1. Test Early, Test Often (Shift-Left Mentality)

This is perhaps the most fundamental best practice in modern software development. Issues found early in the development cycle are significantly cheaper and easier to fix than those discovered in later stages, especially in production.

• Policy Prototyping and Validation: As soon as a new policy is designed or configured in Anypoint API Manager, test it. Don't wait until the entire proxy is deployed. Small, isolated tests for individual policies can catch conceptual errors or misconfigurations immediately.
• Continuous Integration: Integrate your automated test suites into your CI/CD pipeline. Every code commit or configuration change to the proxy should trigger a full set of tests. This ensures continuous validation and immediate feedback, preventing small issues from escalating.
• Developer-Led Testing: Empower developers to write and execute tests for the proxy configurations they implement. This promotes ownership and embeds quality from the very beginning.

2. Automate, Automate, Automate

Manual testing is prone to human error, time-consuming, and unsustainable for large-scale or frequently changing API landscapes.

• Prioritize Regression Tests: Any test that needs to be run repeatedly (e.g., after every deployment, after every code change) should be automated. This includes functional tests for all policies and routing rules.
• Automate Performance Baselines: Set up automated performance tests that run regularly (e.g., nightly) against a stable environment to detect performance regressions early.
• API-First Automation: Since proxies are API-driven, leverage API testing frameworks extensively. They are typically faster, more reliable, and easier to maintain than UI-based tests.
• Scripting for Security: While full penetration testing often involves manual expertise, many basic security checks (e.g., invalid token attempts, simple injection patterns) can be scripted and automated.

3. Isolate Dependencies (Mock Backend Services)

Testing a proxy in isolation from its backend services offers several advantages.

• Focused Testing: Allows you to verify the proxy's behavior (policy enforcement, routing, error handling) without being influenced by the availability or performance of the backend service.
• Independent Development: Development teams working on the proxy can proceed without waiting for the backend service to be fully implemented.
• Controlled Scenarios: Enables the simulation of specific backend responses (e.g., 500 Internal Server Error, 404 Not Found, slow responses) that might be difficult to reliably trigger from a real backend.
• Tools: Use mock servers (e.g., WireMock, MockServer, or even a simple Mule app acting as a mock) to simulate backend API behavior during proxy testing.

4. Version Control Test Assets

Treat your test cases, test data, and test scripts as first-class citizens, just like your application code.

• Store in VCS: Keep all automated test assets (Postman collections, JMeter test plans, Karate feature files) in a version control system (e.g., Git) alongside your proxy configurations or api definitions.
• Review and Collaboration: This facilitates code reviews, collaboration among testers and developers, and provides a clear history of changes.
• Reproducibility: Ensures that specific versions of the proxy can be tested with corresponding versions of the test suite.

5. Use Realistic Test Environments

The closer your test environments resemble production, the more confident you can be in your test results.

• Mirror Production: Staging or pre-production environments should ideally mimic the production environment in terms of infrastructure, data volumes (anonymized), network configuration, and external service integrations.
• Dedicated Environments: Avoid testing in shared development environments where changes from other teams might interfere with your tests. Dedicated, isolated environments for QA and performance testing are crucial.
• Configuration as Code: Use infrastructure-as-code and configuration-as-code principles to provision and manage your test environments, ensuring consistency and reproducibility.

6. Monitor and Alert (Post-Deployment)

Testing doesn't stop once the proxy is in production. Continuous monitoring is a form of ongoing, real-world testing.

• Real-time Observability: Utilize Anypoint Monitoring, APM tools, and log aggregation systems to gain real-time insights into the proxy's performance, error rates, and policy violations.
• Proactive Alerts: Configure alerts for critical metrics (e.g., high error rates, increased latency, sustained policy rejections, resource exhaustion). This enables proactive issue detection and resolution before users are significantly impacted.
• Synthetic Transactions: Deploy synthetic monitors that periodically make calls to your proxied APIs to verify their availability and performance from an external perspective.

7. Foster Collaboration Among Teams

Effective testing is a shared responsibility.

• Dev-QA-Ops Alignment: Ensure clear communication and collaboration between developers (who write the code/configs), QA engineers (who design and execute tests), and operations teams (who monitor and maintain the proxy in production).
• Shared Understanding: Developers should understand the test requirements, and QA should understand the implementation details of the proxy. Operations should be aware of the performance characteristics and common failure modes identified during testing.
• Cross-Functional Teams: Encourage cross-functional teams where testers are embedded within development teams, promoting early and continuous testing.

8. Document Test Cases and Results

Good documentation is vital for knowledge transfer, auditability, and continuous improvement.

• Clear Test Cases: Document test cases with clear steps, expected outcomes, and any specific test data required. This is especially important for complex policy scenarios.
• Audit Trail: Maintain an audit trail of test execution results, including who ran the tests, when, against which environment, and with what outcome. This is crucial for compliance and demonstrating due diligence.
• Knowledge Base: Create a knowledge base for common issues found during testing, their root causes, and resolutions.

9. Consider Edge Cases and Negative Scenarios

While "happy path" testing is necessary, comprehensive testing requires a focus on what happens when things go wrong.

• Boundary Conditions: Test inputs at the absolute limits of what is allowed (e.g., minimum, maximum, empty strings for fields).
• Invalid Inputs: Send requests with incorrect data types, out-of-range values, or missing mandatory fields.
• Unusual Characters/Encodings: Test with special characters, different encodings, or unusually long strings to uncover parsing or sanitization issues.
• Race Conditions: For performance-sensitive policies, consider scenarios where multiple requests arrive simultaneously to test for race conditions.

By meticulously implementing these best practices, organizations can build a testing regimen for their MuleSoft Proxies that is not only thorough and efficient but also adaptable to the ever-changing demands of a dynamic api landscape, ensuring the highest levels of security, performance, and reliability for their crucial api gateway infrastructure.

Conclusion

In the intricate tapestry of modern enterprise architecture, MuleSoft Proxies serve as indispensable api gateways, acting as the intelligent front door to your valuable backend services. They are the critical enforcement points for security, the orchestrators of traffic, and the providers of crucial observability into your API ecosystem. The decision to deploy such a powerful component comes with a corresponding responsibility: the unwavering commitment to rigorous and comprehensive testing.

This guide has traversed the multifaceted landscape of MuleSoft Proxy testing, emphasizing that its importance extends far beyond mere technical validation. Untested proxies pose significant risks, from compromising data security and violating compliance regulations to degrading customer experience and inflicting severe damage on an organization's reputation and bottom line. Understanding the core functionalities of a MuleSoft Proxy – its role in policy enforcement, traffic management, routing, and observability – underscores why each aspect demands meticulous scrutiny.

We have detailed the various types of testing essential for a robust api gateway: functional testing to validate every policy and routing rule, performance testing to ensure scalability and responsiveness under load, and security testing to proactively identify and mitigate vulnerabilities. Furthermore, we explored a rich arsenal of tools, from manual explorers like Postman to sophisticated automated frameworks like JMeter, Gatling, and Karate DSL, illustrating how they can be leveraged effectively. The discussion culminated in outlining a strategic approach and best practices that emphasize early testing, automation, continuous integration, isolation of dependencies, and real-world scenario simulation.

By embracing a "shift-left" mentality and embedding automated tests into every stage of the development and deployment lifecycle, organizations can transform their MuleSoft Proxy testing from a reactive chore into a proactive quality assurance mechanism. This strategic investment in testing ensures that your api gateway operates with unyielding reliability, impenetrable security, and optimal performance, becoming a resilient cornerstone of your digital strategy. In an era where APIs are the lifeblood of innovation, a well-tested MuleSoft Proxy is not just an advantage; it is a fundamental prerequisite for sustained success and competitive differentiation.

---

Frequently Asked Questions (FAQs)

1. What is the primary purpose of a MuleSoft Proxy, and how does it differ from directly deploying an API? A MuleSoft Proxy acts as an api gateway or a façade for your backend API services. Its primary purpose is to decouple clients from the backend, allowing for centralized policy enforcement (security, throttling, caching), traffic management, and routing without modifying the backend code. When you directly deploy an API, the backend service itself is exposed, and it must handle all these concerns internally, potentially leading to redundant logic and less flexibility. The proxy provides an additional layer of control and abstraction.

2. Why is comprehensive performance testing crucial for a MuleSoft Proxy? Comprehensive performance testing (including load, stress, and spike testing) is crucial for a MuleSoft Proxy because, while it adds valuable features, it also introduces an additional hop in the request path. Misconfigured policies or insufficient resource allocation for the proxy can become a significant performance bottleneck, leading to slow response times, timeouts, and service unavailability under load. Performance testing identifies these bottlenecks, ensures the proxy can handle expected traffic volumes, and validates its scalability and resilience under extreme conditions, confirming that the api gateway contributes to, rather than detracts from, overall system performance.

3. What are some key security aspects to focus on when testing a MuleSoft Proxy? When testing a MuleSoft Proxy for security, key aspects include verifying that all configured security policies are correctly enforced and cannot be bypassed. This involves: * Authentication & Authorization: Ensuring valid credentials/tokens grant access, while invalid, expired, or missing ones are correctly rejected. Testing for token manipulation attempts and proper role-based access control. * Input Validation & Threat Protection: Sending malicious payloads (e.g., SQL injection, XSS) to confirm the proxy blocks them and prevents them from reaching the backend. Testing for large or malformed inputs that could lead to DoS attacks. * IP Whitelisting/Blacklisting: Verifying access control based on source IP addresses. * Error Message Disclosure: Ensuring error messages do not leak sensitive backend information. These tests are vital as the api gateway is the first line of defense.

4. How does the "shift-left" approach apply to testing MuleSoft Proxies? The "shift-left" approach applies to MuleSoft Proxy testing by advocating for the integration of testing activities as early as possible in the development lifecycle. Instead of waiting until the proxy is fully deployed, this means: * Early Policy Validation: Testing individual policies as soon as they are configured in Anypoint API Manager. * Developer-Led Testing: Empowering developers to test their proxy configurations during implementation. * CI/CD Integration: Embedding automated functional, performance, and security tests into Continuous Integration/Continuous Delivery pipelines, so every change triggers immediate validation. This catches issues when they are cheapest and easiest to fix, preventing them from progressing to later stages.

5. Can I use open-source tools for testing MuleSoft Proxies, and if so, which ones are commonly recommended? Yes, you can absolutely use open-source tools for testing MuleSoft Proxies. Several powerful options are widely recommended: * Newman: For automating Postman collections from the command line, ideal for functional and regression testing in CI/CD. * JMeter (Apache JMeter): A robust tool for performance testing (load, stress, endurance) that can simulate high traffic volumes. * Gatling: Another high-performance load testing tool, known for its developer-friendly DSL and detailed reports. * Karate DSL: A versatile API test automation framework that uses a simple BDD syntax for functional, regression, and even basic performance testing. * OWASP ZAP (Zed Attack Proxy): For basic security scanning and identifying common web application vulnerabilities in the proxy's exposed endpoints. These tools provide cost-effective yet powerful options for a comprehensive api gateway testing strategy.

🚀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.