The questions enterprises ask.
Our answers, in public.

No. Karate Agent is 100% self-hosted via Docker — browser sessions, test data, screenshots, and video recordings all stay inside your infrastructure. When paired with a local LLM via Ollama, the entire verification pipeline runs air-gapped — no data crosses your firewall, not even for model inference. This is the primary deployment pattern for customers in regulated financial services and insurance.

Karate Agent is provider-agnostic. Works out of the box with Claude (Anthropic), GPT (OpenAI), Gemini, Gemma, Llama, Mistral, and any other model served via Ollama. Switching providers is a configuration change — no test rewrites. This also means enterprise teams can evaluate multiple LLMs against their workload and pick based on cost, latency, or accuracy without vendor lock-in.

Hybrid architecture: the LLM is isolated to a narrow recovery path. Most test steps run as deterministic scripted flows (plain .js files) at native JavaScript speed with zero LLM calls. The LLM is only invoked when a scripted step fails — it analyses the page and attempts recovery. This gives you deterministic happy-path runs with AI-powered resilience only where it matters, so non-determinism is bounded rather than pervasive.

Two mechanisms keep costs low: (1) Scripted flows consume zero tokens — the LLM is only called on failure, so costs scale with flakiness, not test volume. (2) The look() diffing function and structured JSON responses reduce page scans by 72x vs. sending full HTML on every step. Typical enterprise runs spend a fraction of what pure-LLM browser agents consume. See how it works for the full cost model.

Two layers of resilience: Display-text locators let tests reference visible text like {button}Submit instead of brittle CSS/XPath. Cosmetic UI refactors (class renames, DOM restructuring) don’t break tests. When a step still fails, LLM-powered recovery analyses the page and adapts the action on the fly. Net effect: tests survive UI changes that would break traditional Selenium/Playwright suites, with no maintenance sprint required.

Yes. Docker deployment is self-contained. Pair Karate Agent with a local model (Gemma, Llama, Mistral, Qwen) via Ollama and the entire stack — browser, Agent, LLM — runs on your hardware with no internet connectivity. No telemetry, no model calls, no update checks phoning home. Requirements: Java 21 + Docker.

Every session produces: (1) H.264 video recording at 8 fps of the full browser session; (2) structured step logs with timestamps; (3) complete execution history with request/response details; (4) live noVNC dashboard for real-time viewing, pausing, command injection, and resumption. Evidence is stored in your infrastructure — retention policy is yours to control.

Self-hosted Docker deployment with full session isolation. Each test session runs in its own container with a dedicated Chrome instance — no shared state across runs. Minimum requirements: Java 21 + Docker. Kubernetes orchestration is supported for horizontal scale. A standard REST API triggers test runs, so a single curl command integrates with Jenkins, GitHub Actions, Azure DevOps, GitLab CI, or any pipeline. See deployment docs for reference architectures.

Yes — this is what Karate Agent is purpose-built for. Cursor-pointer discovery handles dynamic widgets and shadow DOM elements that defeat traditional automation tools. In production use with Guidewire (insurance), Salesforce, ServiceNow, and other complex SPAs where Selenium/Playwright-style selectors are brittle or unmaintainable. Karate Labs is Guidewire’s first and only technology partner for testing technologies — see Insurance.

Karate Agent exposes a karate_eval tool via the Model Context Protocol (MCP). Developers can drive the Agent from Claude Code, VS Code Copilot, Cursor, and other MCP-compatible clients — generating tests, exploring flows, and verifying behaviour without leaving the editor. This turns the AI assistants developers already use into first-class test-authoring partners.

Different tools for different jobs — many enterprise teams use both: Karate framework for deterministic API testing, contract testing, mocking, and scripted UI automation where selectors are stable. Karate Agent for UI verification where resilience matters: complex SPAs, UIs that change frequently, flows where traditional selectors can’t keep up. The common pattern: framework for API + backend contract tests, Agent for end-to-end UI verification of the same application. Same team, shared dashboard, one vendor.

Enterprise SSO via your existing identity provider (SAML / OIDC) with role-based access control. No per-seat installs — a single shared dashboard lets the whole team view results, watch recordings, and manage sessions. Session isolation ensures tests from different users or teams never share state. Full per-session audit trail (video + logs + history) ties every action back to its originator.

Yes — zero-migration positioning. Xplorer imports existing Postman collections (v2.1 JSON) as-is. Requests, environments, variables, and headers come across intact. Insomnia export files and cURL commands are also supported. Most teams are productive on day one without retraining or collection rebuilds.

100% local. API keys, collections, environment variables, request history, and response payloads live only on the developer’s machine — never synced to any cloud service. This is the primary differentiator vs. SaaS API clients that store credentials and payloads on their servers. No account required. No telemetry required. No network calls needed to use core features.

The built-in LLM agent does three things: (1) suggests assertions based on observed response structure; (2) generates test scenarios for positive, negative, and edge cases; (3) explains API behaviour in plain English for unfamiliar endpoints. Integrated via MCP, so you can plug in Claude, GPT, or a local model via Ollama. You bring the LLM credentials — costs are yours to control, and keys never leave the device.

Xplorer runs natively on: macOS (Apple Silicon + Intel), Windows (x64), and Linux (x64). Single signed installer per platform. No JVM setup, no Docker, no runtime prerequisites. Runs offline after install — suitable for restricted networks and air-gapped developer laptops.

REST (all HTTP methods, headers, cookies, auth schemes), GraphQL, and SOAP / XML are natively supported. Request chaining lets you extract values from one response and inject them into the next call. JSON, XML, and form-encoded payloads are handled with syntax highlighting and structured response views.

One-click export. Any request or chain explored in Xplorer can be converted to Karate .feature files with a single action. The exported test uses the same assertion syntax, so what you verified interactively becomes a deterministic CI/CD-ready regression test. This closes the Postman -> Newman gap — no rewriting, no separate automation framework.

Named configuration profiles with per-environment variables (base URLs, tokens, feature flags). Switching between dev, staging, and production is one click — no request rewrites. Shared variables can be referenced across requests and chains. All environment data stays on the local device; no cloud sync.

Yes. Parameterise any request with CSV, JSON, or inline data sets. Xplorer runs the same call across every row, surfacing pass/fail per iteration. Edge-case coverage (boundary values, negative inputs, locale variants) is achieved without duplicating requests. Data-driven runs export to Karate feature files the same way as single requests.

Yes. Core features (exploration, chaining, environments, data-driven testing, Karate export) work with no internet connectivity. License activation is the only step that requires network access — and offline / airgap activation is available for enterprise customers. LLM features can be run against a local model via Ollama, keeping even AI-assisted workflows fully offline.

Three complementary products along one journey: Xplorer for interactive API exploration and ad-hoc testing — the desktop client. Karate framework for automated API + backend tests in CI/CD — written in Gherkin-like syntax, runs in parallel. Karate Agent for AI-powered UI verification against complex SPAs. Exports flow in one direction: Xplorer -> Karate feature files -> Agent flows. Same assertion language across all three.

100% local. Karate Labs software runs on the user’s desktop or inside your own infrastructure. No customer application data, test data, or screenshots are stored in our cloud. Only billing (Stripe) and SSO authentication (WorkOS, Google Cloud, Microsoft Azure) are delegated to industry-standard cloud providers. Enterprise customers can opt for offline license activation so no outbound calls are made during operation.

No. Karate Labs has had zero security incidents in the past 4 years. See our public Trust & Security page for the full disclosure posture.

Multiple overlapping layers: (1) Maven Central + Sonatype block releases with critical vulnerabilities; (2) GitHub Dependabot continuously scans the repository with auto-generated PRs for most remediations; (3) Community scanning — 600+ enterprise customers using Snyk or similar tools flag issues quickly, often with a PR attached; (4) Plugin marketplace review — JetBrains and Microsoft verify every plugin submission; (5) User-controlled dependency overrides let customers mitigate CVEs without waiting for an official release. All vulnerabilities are publicly disclosed via GitHub Security Advisories.

Four providers, each with their own security program, and none of them receive customer application or test data: (1) Stripe — billing and subscription management; (2) WorkOS — SAML SSO identity management for enterprise customers (Okta, Azure AD, Ping, Auth0 supported); (3) Google Cloud — OAuth flows; (4) Microsoft Azure — OAuth flows. Enterprise customers preferring no outbound calls can opt for offline license activation, removing WorkOS from the picture entirely.

Yes. Karate framework, IDE plugins, Xplorer, and Karate Agent all run locally. Offline license activation is available for enterprise customers — no outbound calls to validate license, no telemetry, no update checks phoning home. Karate Agent paired with a local LLM via Ollama provides a fully air-gapped AI testing pipeline suitable for regulated and classified environments.

The core Karate framework is open source and its dependencies are published on Maven Central. Current dependencies are listed per release, for example: karate-core dependencies. The IntelliJ plugin and VS Code plugin dependencies are published on their respective marketplaces. A per-release Software Bill of Materials (SBOM) PDF is attached to every GitHub release.

No. Karate Labs does not use customer data in the processing or training of AI models. Karate Agent is a self-hosted product where the customer brings their own LLM (Claude, GPT, Llama, Qwen, etc.) and runs it on their own infrastructure. Karate Labs has no visibility into, and no access to, customer data in that pipeline.

Not applicable to Karate Labs. Because our software runs locally on the user’s desktop and no customer data is stored on our cloud, Karate Labs has no access to customer data in production, non-production, or any environment. Data handling within customer environments is governed by the customer’s own policies and controls.

Karate Labs has stringent internal security controls including antivirus, file integrity monitoring, continuous logging, and principle-of-least-privilege access. Source code is managed in GitHub with continuous vulnerability scanning via Dependabot and Sonatype. License activation enables only the features allowed by the customer’s license tier, with no broader system access.

Two dimensions. For our own business: all internal data is backed up via Microsoft OneDrive; supporting providers (Stripe, WorkOS, Google, Microsoft Azure) maintain their own DR programs. For customers: because Karate runs locally on customer infrastructure, customers follow their own DR controls for their Karate deployment. There is no dependency on Karate Labs uptime once software is activated (particularly with offline license activation).

Two channels: (1) Email info@karatelabs.io with subject "Security — [summary]", including reproduction steps and impact. (2) Submit privately via GitHub Security Advisories for open-source framework vulnerabilities. We publicly disclose confirmed vulnerabilities after remediation; researchers are credited in the advisory. See the Trust & Security page for the full policy.

Three ungated assets available on our Trust & Security page: (1) Security Compliance document (PDF, 15 pages) — full security posture with responses to common vendor questionnaires; (2) Security FAQ (PDF, 14 pages) — detailed answers to common enterprise security questions; (3) Per-release SBOM (PDF) — Software Bill of Materials attached to every GitHub release. Additional attestations, live security questionnaire completion, and calls with your security team are available on request.

Karate is an open-source unified test automation platform combining API testing, API performance testing, API mocks & UI testing.
The syntax is language-neutral, easy for non-programmers. Assertions and HTML reports are built-in, and tests run in parallel for speed.
Cross-platform standalone executable available. No compilation needed — write tests in a simple, readable syntax designed for HTTP, JSON, GraphQL and XML.
Karate Labs was founded in Dec 2021 with a commitment that all of Karate open-source will remain under MIT License and free.
Licensed software for enterprise users: AsyncAPI Testing (Kafka, gRPC, Websocket, Webhook), OpenAPI/Swagger support, API Conversion, Xplorer, and official IDE Plugins (IntelliJ, VS Code).

Open Source options: Maven, Gradle, Standalone JAR, Docker, Docker + Standalone JAR, NPM, JBang, Custom Built (Fat) JAR.
Licensed Plugins: IntelliJ and Visual Studio Code — installed via JetBrains and VS Marketplace. Frictionless, no support from Karate Labs needed.

Comprehensive documentation for open-source and all licensed components: IntelliJ Plugin, VS Code Extension, Kafka, gRPC, Websocket, Webhook, Xplorer.

All Karate open-source and closed-source elements are cross-platform (JVM-based) and run on Windows, Mac, and Linux. IDE plugins also cross-platform. Typical for test suites to run on CI/CD agents in the cloud (Jenkins, GitHub Actions, Azure, etc.).

Minimal memory or CPU requirements. Runs well on average developer workstations or CI/CD nodes. Common for teams to run multi-threaded for speed. Never seen as a serious concern.

Java (Maven/Gradle) based, integrates into existing Java projects. Reports in JUnit XML and Cucumber JSON formats for seamless CI/CD integration. Easily extensible — adding hooks or connectors is low effort. Public integrations for ReportPortal and X-Ray.

Yes. Karate has a configuration system designed to make switching URLs or secrets between environments as easy as possible.

Best interface is the IDE plugin. Formatting support, code colouring, syntax autocomplete, error hints. Running tests from the IDE is simple via icons or shortcuts; HTML report is one click away.

Yes. REST (primary), SOAP, and GraphQL are all supported.

Kafka: Native support as a licensed feature with dedicated Karate syntax.
gRPC: Native support as a licensed feature.
Other MQ systems (IBM MQ, RabbitMQ, etc.): Supported via Java interop. Enterprise teams have successfully integrated various MQ systems using Karate’s Java extensibility.
Websocket and Webhook: Native support available.

Karate supports SOAP/XML testing natively with built-in XML assertions and namespace handling.
WSDL-based automatic test generation is not built-in. SOAP endpoints defined in WSDL can be tested directly by referencing endpoint URLs and constructing XML payloads.
For teams with extensive WSDL-first workflows, Java interop can be used to parse WSDL and generate test templates.

Yes. Two different approaches to loop over data. JSON and CSV files directly supported. Data sources can be created dynamically at runtime. Databases handled by Java adapter that reads rows into JSON.

Yes. Karate is designed to make this as easy as possible. Multiple API methods can be called on the same REST resource in the same test (Scenario).

Yes. JavaScript can be mixed into test scripts for complex business rules. Java code can also be mixed in for maximum extensibility.

Yes. Reuse of feature files or individual Scenario definitions. For large projects, assets can be packaged for reuse across multiple teams.

Yes. The Karate IDE plugin can import OpenAPI spec and generate Karate tests and mocks.
No-code drag-and-drop interface for customizing API call sequences.
Impact analysis when the OpenAPI spec changes, showing which tests and mocks need updating.
Note: manual chaining and assertions for business rules still needed on generated tests.

Yes, via Java interop. Calls to databases and any external non-HTTP integration. Many enterprise teams have done this successfully.

Yes. Karate has API mocking built-in. IDE plugin can generate an API mock from an OpenAPI or Swagger spec.

Not supported.

Yes. Custom JavaScript easily plugged in for this purpose. Easy to hook into existing SSO systems. OAuth2 token retrieval and refresh supported. JWT handling natively supported.

Supported via Java interop. Karate’s extensibility allows integration with WS-Security libraries (e.g. Apache WSS4J) for SOAP message signing, encryption, and security token handling.
Not a native built-in feature — requires Java adapter implementation. Enterprise teams in financial services have implemented this successfully.

Supported via Java interop. Karate can integrate with Kerberos authentication using Java’s built-in GSSAPI/SPNEGO support or Apache HttpClient Kerberos modules.
Enterprise teams in regulated industries have implemented Kerberos flows using Karate’s Java extensibility.
Not a native built-in feature — requires Java adapter configuration for KDC connectivity and ticket management.

Yes. Natively supported via Karate’s HTTP header and configuration system. Single line of configuration.

Yes. Standalone JAR, Maven, Gradle, Docker. Full CLI support.

Yes. Works well on CLI, straightforward integration. Many enterprises use Karate within Azure, Jenkins, GitHub Actions, and GitLab CI. Reports in JUnit XML and Cucumber JSON for seamless pipeline integration.

Yes. Core feature of Karate that sets it apart. Tests run in parallel with a single aggregated report.

Yes. Configuration system designed to switch URLs or secrets between environments easily.

Yes. Built-in tagging system designed for this need. Tags appear in reports. Tags commonly used to connect execution reports to 3rd party requirements or reporting systems.

Naturally handled — Karate is plain-text. All IDEs supporting Git workflows work as expected (diffs, version history, concurrent development, branching, PRs, merging, collaboration).

Not built-in. This is a function of CI/CD tools. Most teams use CI/CD pipelines to trigger Karate tests on code changes or at regular intervals. Karate’s CLI integration enables this.

Existing integrations with X-Ray. Adding other integrations is simple — Karate’s report output can be tapped via Java API or JSON dump.

Yes. HTML, JUnit XML, Karate JSON (contains all data), and Cucumber JSON format.

Yes. HTML report is the primary source for post-run analysis and troubleshooting. Traditional logging also available with customizable log levels.

Built-in HTML report has test summary (features/scenarios run, pass/fail). Cross-run aggregation is the responsibility of CI/CD setup or plugins. JUnit XML export makes this straightforward. ReportPortal integration available for richer dashboards.

Not directly supported. Possible to build using a custom hook.

Yes. By default, one test failure does not stop the suite (configurable). Karate has retry-until option to re-try an API call until desired result or status.

No. Logically the responsibility of CI/CD infrastructure (Azure, Jenkins).

Yes. Functional API tests can be reused as performance tests with comprehensive reporting. By default, normal tests report time per response.

Yes. The Karate-Gatling integration allows for elaborate load models: long-running tests, multiple user types, specific load characteristics (e.g. simultaneous actions).

Built on Gatling 3.13.5. Existing Karate .feature files run as performance tests with no rewriting — same assertions, request chaining, environments, and auth flows carry over. Wrap with karateFeature(...) and an injection profile (e.g. rampUsers(10).during(5)). Karate v2 uses a pure Java DSL; v1 retains Scala for legacy projects. Artifact: io.karatelabs:karate-gatling on Maven Central.

Define a KarateProtocolBuilder with URI patterns (e.g. uri('/users/{id}')) to group requests in reports. Build scenarios with scenario('name').exec(karateFeature(...)). Apply an injection profile via setUp(scenario.injectOpen(rampUsers(...))). Standard Gatling profiles apply — rampUsers, constantUsersPerSec, and others.

Yes for basic coordination — multiple Karate Gatling runs can be coordinated across machines, with IP binding via configure localAddress. Docker containers are a common deployment pattern. Karate doesn't ship a built-in orchestrator for very large-scale runs — teams typically wrap karate-gatling in Kubernetes Job arrays, AWS Batch, or similar.

HTTP/HTTPS is the primary scope. Custom protocol testing (gRPC, Kafka, RabbitMQ) is supported via the PerfContext API, which drives arbitrary Java code under the Gatling load model — useful for putting load on message brokers from inside a Karate scenario. WebSocket performance is not in the standard documentation.

Open source under MIT. karate-gatling is on Maven Central as part of the OSS framework. The Enterprise runtime license requirement applies specifically to async protocols (Kafka, gRPC, WebSocket) executing in CI/CD — not to HTTP performance testing.

Not supported.

Yes. Karate has a reputation of being very easy to pick up. Simple, clear syntax. Many cases of non-programmers writing tests in less than a week.

Documentation, blogs, webinars, tutorials, customer webinars, Karate Kickstart, Karate Learning Center, YouTube Channel.

Karate Learning Center, Hands-on API testing guide, Short tutorials, Pluralsight: Karate Fundamentals, Udemy: Karate DSL course.

Dedicated Slack Channel. No SLA on response unless agreed as part of paid enterprise support contract.

Stack Overflow (tagged questions), GitHub Issues for Karate open-source, IntelliJ plugin issues, VS Code plugin issues.

VS Code extension and IntelliJ plugin. Ease of use, effective features, no security risk, improved developer productivity.

JavaScript and Java extensibility handle any complex need.
Frictionless onboarding: installation via JetBrains and VS Marketplace, no Karate Labs support needed.
Developer productivity: 4 hours to 30 minutes for writing tests for a single endpoint with 60% less code.
Debugging: premium plugin feature includes breakpoints and step-through debugging.
Zero systems administration time/FTEs.
Improved new hire onboarding due to ease of use, docs, and community.

Yes. Docker support is built-in and straightforward. Adding Karate to Docker containers is a standard pattern. Kubernetes orchestration of Karate test containers is fully supported.

Not directly applicable to Karate Labs as a testing tool.
Key differentiator: Karate is a “local-first” solution (not cloud-hosted SaaS). When using Karate for test automation, customer data never leaves the customer firewall.
This has been a primary driver for companies migrating from SaaS providers to Karate.

Karate’s configuration system (karate-config.js) supports environment variables and external config files for secret injection, keeping credentials out of test scripts.
Secrets can be sourced from vault systems (HashiCorp Vault, Azure Key Vault, AWS Secrets Manager) via Java interop.
Karate’s local-first architecture ensures credentials never leave the customer’s firewall — no data transmitted to any external SaaS platform.
Log masking: sensitive values can be excluded from HTML reports and logs through Karate’s configure system (e.g. configure logPrettyResponse = false for specific calls).

What & When: Karate’s HTML and JSON reports capture complete test execution details including timestamps, test names, assertions, and pass/fail status.
Who: Test execution identity is managed through CI/CD pipeline metadata (commit author, pipeline trigger identity) and Git history. Since Karate tests are version-controlled plain-text, the full audit trail of authorship and changes is maintained in Git.
For enterprise environments requiring user-level execution tracking, the CI/CD layer (Jenkins audit trail, Azure DevOps activity logs) provides this capability using Karate’s standard report outputs.

Karate’s local-first architecture provides the baseline: no test data ever leaves the customer’s firewall.
For masking in logs and reports: Karate’s configure system can suppress response logging for specific API calls (configure logPrettyResponse, configure logPrettyRequest).
Custom masking functions can be implemented in JavaScript or Java and applied to sensitive fields before logging or reporting.
For enterprise deployments handling PII or financial data, teams typically implement a thin Java adapter that intercepts and redacts sensitive fields in report output.

Karate supports dynamic data generation at runtime using JavaScript functions within test scripts (e.g. random strings, UUIDs, dates, calculated values).
For richer synthetic data (e.g. realistic names, addresses, financial data): Java libraries such as Faker or Datafaker can be integrated via Karate’s Java interop with minimal effort.
CSV-driven and JSON-driven data sources can be combined with dynamic generation for parameterized test data at scale.
Dedicated synthetic data generation UI is not built-in.

Not built-in natively. Karate focuses on individual test run excellence.
Test trend analysis is achieved through CI/CD infrastructure using Karate’s JUnit XML and JSON exports:
• Jenkins: built-in test result trend graphs.
• Azure DevOps: test analytics dashboards.
• ReportPortal: dedicated integration available for historical trend analysis, flaky test detection, and cross-run comparison.
Teams typically configure their CI/CD pipeline to archive Karate reports and feed them into their preferred analytics tool.

Not built-in natively.
Comparison across runs is achieved via ReportPortal integration or CI/CD tooling.
Since Karate exports to industry-standard formats, any comparison tool that reads JUnit XML can be used.

License management: Karate’s enterprise admin portal supports provisioning, assignment, and tracking of licenses by user/seat with status visibility.
Test asset access control: Managed through existing repository permissions (Git/BitBucket). Branch protection, PR approvals, and folder-level access are handled by your Git platform.
IDE-level: Standard IDE workspace and project permissions apply.
Karate does not have a built-in RBAC system for test execution — this is managed through your CI/CD and repository governance layer.

Managed through standard Git workflows: pull requests, code reviews, branch protection rules, and approval gates.
Karate does not have a built-in approval workflow, but because tests are plain-text feature files, they integrate naturally into existing review processes.
CI/CD pipeline gates can enforce that tests pass review before being merged or executed in higher environments.

OpenAPI-based generation: Karate’s IDE plugin can auto-generate test cases and mocks from OpenAPI/Swagger specifications, including data variations and endpoint coverage.
Karate Agent: LLM-powered browser automation product that enables AI-assisted test creation and execution. Available as a licensed product.
Postman/HAR/cURL conversion: Existing API artifacts can be converted to Karate tests, accelerating test creation.
Fully autonomous AI-based API test generation from natural language descriptions is on the product roadmap.

OpenAPI-based: Generated tests include default assertions based on spec definitions (status codes, schema validation, response structure).
Karate Agent: The LLM-powered assistant can suggest assertions based on observed API behavior and response patterns.
Enhanced AI-powered assertion suggestions (leveraging response patterns and historical test data) are under active development.

Karate generates comprehensive reports (HTML, JUnit XML, Karate JSON) per test run with timestamps and full execution details.
Archiving and revision control of execution records is managed via CI/CD artifact storage (e.g. Jenkins artifact archival, Azure DevOps artifact retention, S3/Blob storage).
For regulated industries requiring immutable audit trails: CI/CD pipelines can be configured to push Karate reports to write-once storage (e.g. AWS S3 Object Lock, Azure Immutable Blob Storage).
Karate’s local-first architecture ensures all execution data remains within the customer’s controlled infrastructure.

Test execution logging: Karate’s HTML reports and detailed logs capture all test execution activity including requests, responses, assertions, and timing.
User action logging: Managed through Git history (who created/modified tests, when, what changed) and CI/CD audit trails (who triggered execution, pipeline logs).
License management portal tracks activation and usage activity.
Karate does not have a built-in centralized audit log system — enterprise audit requirements are met through the combination of Git, CI/CD, and Karate’s execution reports.

Native — no Selenium or Playwright dependency. The primary engine is a rewritten Chrome DevTools Protocol (CDP) driver. W3C WebDriver is built in for cross-browser testing (Firefox via geckodriver, Safari via safaridriver, Chrome/Edge via their drivers) and passes 100% of the W3C test suite. Playwright integration is available as an optional layer for advanced scenarios. Same Gherkin syntax for UI and API. See the UI testing docs.

Chrome and Chromium-based browsers (including Edge) are driven directly via CDP — no WebDriver executable required — with the fastest performance via a direct WebSocket connection on port 9222. Cross-browser via W3C WebDriver: Firefox (geckodriver), Safari on macOS (safaridriver), Chrome and Edge via their drivers. Remote drivers supported via Selenium Grid, SauceLabs, BrowserStack, and any W3C-compliant cloud provider.

Yes — the unified test surface is Karate's signature differentiator. A single .feature file can call APIs, validate responses, then drive a browser to verify UI state, all sharing variables and scope. A common pattern is API pre-authentication: get an auth token via API and inject it as a cookie to skip the login screen, saving 5–10 seconds per test. This catches integration mismatches that siloed API-only or UI-only tests miss.

Karate v2 automatically waits before every element operation (click, input, etc.), dramatically reducing explicit waits. Explicit waits remain available: waitFor(), waitForText(), waitForUrl(), waitForEnabled(), and waitUntil() for arbitrary JS conditions like document.readyState == 'complete'. Default retry policy is 3 attempts × 3000ms, configurable per test or globally.

Yes to both. Headless is a single config flag (configure driver = { type: 'chrome', headless: true }); screenshots still work in headless. Karate v2 automatically pools browser instances during parallel runs — Runner.path(...).parallel(4) creates and reuses 4 browsers with clean state reset between scenarios (about:blank, clear cookies). Works with chromedp/headless-shell (~200MB), selenium/standalone-chrome, browserless/chrome.

screenshot() captures full-page PNG; screenshot(locator) clips to an element; pdf({...}) exports PDF (Chrome only). Auto-screenshot on failure is on by default — failing steps automatically embed the screenshot in the HTML report. Visual regression is supported via compareImage with baseline images and a configurable failureThreshold.

Two paths. For device emulation in the browser, Karate v2 supports viewport and user-agent override (driver.dimensions = { width: 375, height: 812 }) to simulate iPhone/Android sizes within Chrome. For native mobile apps, Karate integrates with Appium — driver type 'android' or 'ios' against an Appium server, with native locator prefixes (@ for accessibility ID, : for iOS predicate, - for Android UIAutomator). Screen recording supported. Native mobile is mature in v1; v2 refresh in progress.

vs Selenium: Karate uses CDP (faster than HTTP-based WebDriver) with W3C WebDriver fallback for cross-browser. Auto-wait and browser pooling are built in — features Selenium leaves to the user. No Page Object Model boilerplate; locators centralize in JSON-friendly maps. See Karate vs Selenium.

vs Playwright: Karate unifies API + UI in a single test syntax (Gherkin); Playwright keeps them separate. Karate is JVM-native; Playwright is language-agnostic. Both are multi-browser. Playwright has more mature native mobile today; Karate's mobile rides on Appium. See Karate vs Playwright.

Built into Karate — no external dependency. Karate v2 features a rewritten mock server on a Netty HTTP backend, with the same JavaScript engine as the test runtime. Mocks are defined in the same .feature syntax as tests. See the test doubles docs.

Each Scenario in a mock .feature acts as a route handler. Match requests with predicates like pathMatches('/users/{id}') && methodIs('get'); build responses by setting response, responseStatus, and responseHeaders variables. Path parameters extract automatically into pathParams. Other predicates: paramExists, headerContains, bodyPath, typeContains.

Yes. Background variables run once at startup and persist across all requests. A POST handler updates an in-memory store (or calls any Java/JS code); subsequent GETs read from it. Karate's mock server uses thread-safe synchronized request processing, so concurrent requests don't corrupt state. The docs include a complete CRUD example covering POST → GET → PUT → DELETE flows.

Yes. The same .feature mock files run as a standalone HTTP server via the CLI: karate mock -m users.feature -p 8080. HTTPS (--ssl), multiple mock files, and hot-reload (-W) are supported. Other teams point their services at it like any other HTTP dependency — useful for end-to-end environments where a downstream system isn't yet built. Embeddable in Java via MockServer.feature(...).http(0).build() for tests.

Yes — proxy mode is built in via karate.proceed(url). Forwards requests to a real backend, optionally modifying the response before returning to the client. Useful for selectively stubbing specific endpoints while letting the rest flow to a real service — particularly powerful during incremental migrations or for simulating failure modes on specific endpoints without rebuilding the entire backend.

HTTP mocking is in core open-source Karate. Async mock primitives for Kafka, gRPC, WebSocket, and webhooks are part of the Karate Enterprise async pack — useful when you need to simulate message brokers in test or QA environments without standing up real infrastructure. Same Karate syntax across HTTP and async. See the async testing page.

The HTTP mock server is open source under MIT, part of core Karate. Async mock primitives (Kafka, gRPC, WebSocket) require the Karate Enterprise async pack license for production CI/CD execution.