Your test data no longer needs to live inside every mock rule. With Datasets, you can import JSON, NDJSON, or CSV records once and use them in mock responses. Use incoming query parameters to look up records and build dynamic responses. You can share the same dataset across authorized endpoints in your organization and refresh records independently without rewriting rules.

Put it to work:

• Keep test data centrally managed.
• Build realistic responses by combining dataset lookups with other template helpers.

An external dependency that feels fast in development can become your bottleneck at peak traffic. With Request Rate Based latency, you can define how much delay Beeceptor should add at different request rates. Choose gradual increases or jumps at thresholds. Your performance test supplies the traffic; Beeceptor adjusts the delay as the measured rate changes.

Put it to work:

• Simulate a payment provider slowing down during a flash sale.
• Check whether retries amplify traffic and make a slowdown worse.
• Exercise timeouts, circuit breakers, and fallback flows as load climbs.
• Compare application changes against the same configured dependency latency curve.

Filtering requests by query parameters is now even easier. You can now directly combine query parameter filters with path, method, and header conditions to precisely target incoming requests and simulate behaviors. While Beeceptor has long supported query parameter filtering, this fully integrated support streamlines the process, making it much faster to debug and fine-tune your API simulations. Check out the quick demo to see how it works in action.

Beeceptor now makes it easy to promote a proven configuration from one endpoint to another with Pull Snapshot. You can copy a restorable snapshot directly into the endpoint (asset or mock-server) you are working on, reducing manual setup, avoiding configuration drift, and having a controlled promotion process across environments.

Common use cases:

• Promote tested configurations from development to QA or staging.
• Standardize mock rules and endpoint settings across team environments.
• Share your setup with your team for approved configurations.

Configuration Snapshots are here. Save your endpoint’s mock rules, responses, settings, and other configuration as a single restorable configuration. You can create multiple snapshots, switch between test setups, or roll back when a change causes regressions. It’s a simple way to preserve known-good configurations without rebuilding them manually.

Common use cases:

• Before major changes: Save a known-good state before updating rules, contracts, or settings.
• Switch test scenarios: Jump between different QA, integration, or environment configurations.
• Recover from regressions: Restore a stable setup when new changes break existing tests.
• Demo configurations: Keep polished, reliable setups ready for customer demos and workshops.
• Restore Points: Create reliable backups as your virtual services evolve.

Use snapshots to move faster without worrying about losing a working setup.

Beeceptor now supports the HTTP QUERY method standardized in RFC 10008. You can now match incoming QUERY requests in mock rules, and inspect these requests in real-time or in request history. (The same reliable way you already use for other HTTP methods.)

Beeceptor now supports Workspaces for grouping related private endpoints and managing access from one place.

A workspace can represent a team, project, service, or environment. All endpoints inside it inherit the same access policy and member permissions. With workspaces, you can:

• Manage access for private endpoints with ease,
• Grant organization wide read-only access to endpoints,
• Assign Read, Write, or Manager roles.

Workspaces are available on the Enterprise plan and are managed by organization administrators.

Beeceptor now lets you apply latency behavior across an entire virtual server. Use a fixed delay, random range, log-normal distribution, or load-based latency that increases as traffic grows.

This gives QA and performance engineers a practical way to test timeouts, retries, fallback paths, and degraded dependency behavior without adding delays to every mock rule.

You can still override latency at the rule level for specific test scenarios.

At Beeceptor, we recently completed comprehensive performance benchmarking across static, dynamic, delayed, and mixed virtual API scenarios. These tests passed through sustained traffic stages up to 6 million transactions per hour (~1,667 requests per second) while showcasing predictable latency and stable behavior.

Configured response delays remained deterministic throughout the tests. Client-side measurements recorded p95 latency as low as 3.10 ms. Comparisons across static and dynamic responses, multiple virtual APIs, mixed request modes, payload sizes ranging from 10 KB to 100 KB, and intentionally induced latency all performed consistently within the planned capacity and expectations.

When horizontally scaled, Beeceptor sustained the most demanding workload with 0% HTTP request failures, while p95 latency remained closely aligned with the maximum configured response delay. This predictable behavior after adding capacity validates Beeceptor’s scale-out architecture. Built on Node.js and asynchronous I/O, Beeceptor is designed to handle highly concurrent virtual API traffic as deployments grow. Application-host metrics, including CPU and memory utilization, were tracked throughout the benchmark to correlate platform performance with infrastructure capacity.

These results reinforce our confidence in Beeceptor as an enterprise-ready service virtualization platform for reliable, repeatable performance testing.

Contact the Beeceptor support team to request access to the complete benchmarking report.

Beeceptor now lets you configure the default response for unmatched requests. This is useful when you want unknown API paths to fail explicitly instead of receiving the default 200 OK response.

For example, you can configure an endpoint to return 501 Not Implemented whenever a request does not match any Mock Rule or OpenAPI route.

How this works:

• Mock Rules continue to take highest priority.
• Requests matching your OpenAPI specification still receive generated mock responses.
• Requests that match neither will return your configured fallback response (such as 501 Not Implemented).