Forem: Arti Jain

APIs are everywhere. But how do we test them without breaking the bank?

Arti Jain — Fri, 12 Sep 2025 19:07:50 +0000

If you’ve been around long enough, you probably remember the glory days of service virtualization. (If you don't know, i recommend reading this.)

Service Virtualization

Tools like DevTest/LISA, Parasoft, or Microfocus were lifesavers back when databases, message queues, and mainframes were expensive to provision. Every new dev or test environment meant serious cost, and virtualization filled that gap by simulating these components. However, these are expensive as they come with high implementation cost.

But time has changed. Today, spinning up a DB or queue in the cloud is cheap and fast. That old use case lost steam.

Yet, a new challenge appeared. Modern applications don’t just depend on databases: they depend on hundreds of external APIs. Think about it: CRM systems, payment gateways, KYC checks, SMS, video processing, email, analytics, and dev tools. Building software today means stitching together an ecosystem of APIs.

Now here’s the catch: in dev and test, do you really provision sandbox accounts for all these services? Yes, but it’s messy. Rate limits, missing features in sandboxes, duplicated configs, costs adding up, and sometimes sandboxes don’t behave like prod.

Contract Virtualization

That’s where contract virtualization, or simply, mock APIs—becomes a game changer. Modern mocks aren’t dumb stubs. They can be stateful, async, support callouts, or even proxy real calls so you can record and replay. In other words, they let teams test integrations safely, cheaply, and at scale.

I personally recommend checking out Beeceptor. Most mocking tools work fine for trivial cases, static ones, or test data generation. But Beeceptor makes it effortless to start small (mocking a single endpoint) and then scale into complex, real-world scenarios. It supports advanced behaviors like conditional responses, dynamic rules, and deep customization—without forcing you into heavyweight setups.

For teams dealing with dozens of API dependencies and connecting to 3rd party services, Beeceptor acts as that single control layer where you can simulate failures, validate contracts, and unblock development without waiting for third-party sandboxes to cooperate.

Well, this shall look bias opinion, but, yes it is! A personal experience sharing here.

A Quick Intro to Mutual TLS (mTLS)

Arti Jain — Sun, 24 Aug 2025 15:52:19 +0000

Most APIs today run over HTTPS. In a typical setup, the client checks the server’s certificate to make sure it’s talking to the right host. That may be enough when you’re building a public REST API where clients authenticate using API keys or tokens.

But in banking and fintech, the communication is often system-to-system. Think of a bank’s backend calling a payment processor, or two financial institutions exchanging transaction data. In these cases, both sides need to prove who they are. Before any communication starts, the domains/parties has to have trust. Relying only on TLS plus an API key isn’t strong enough.

This is the place Mutual TLS (mTLS) comes in and widely used.

TLS vs. mTLS

Here’s the difference:

TLS (standard HTTPS): The client validates the server’s certificate. The server only sees whatever credentials (API key, OAuth token, etc.) the client sends later in the request.
mTLS: Both the client and the server exchange certificates during the TLS handshake. Each validates the other before any request is processed.

With mTLS, if a client doesn’t have a valid certificate signed by a trusted CA, the connection is dropped immediately. This prevents unknown or unauthorized services from even hitting the secure service endpoints.

Why This Matters in Fintech

In financial systems (fintech), each service is dealing with regulated data, strict compliance rules, and high risk if something goes wrong. Tokens can leak. API keys can get exposed in logs. With mTLS, authentication is baked directly into the connection itself.

That’s why banks, clearing houses, insurance, and payment processors often mandate mTLS for system-to-system integration. It gives both sides cryptographic assurance of who’s on the other end.

Node.js sample: Code to connect to am M-TLS API

Here’s how you’d connect to an mTLS-enabled service using Node’s built-in https module:

const https = require('https');
const fs = require('fs');

const options = {
  hostname: 'api.financial-service.com',
  port: 443,
  path: '/transactions',
  method: 'GET',
  key: fs.readFileSync('client-key.pem'),       // your private key
  cert: fs.readFileSync('client-cert.pem'),     // your client certificate
  ca: fs.readFileSync('ca-cert.pem')            // trusted CA cert
};

const req = https.request(options, (res) => {
  let body = '';
  res.on('data', chunk => body += chunk);
  res.on('end', () => console.log(body));
});

req.on('error', (err) => {
  console.error('Request failed:', err);
});

req.end();

When you run this, Node presents your certificate during the TLS handshake. If the server trusts it, the request goes through. If not, the connection never establishes.

Tooling Gaps

If you’ve used Postman or curl for API testing, you know how smooth the developer experience is with regular APIs. mTLS isn’t quite there yet.

This lack of mature tooling makes mTLS harder to adopt, especially for teams that need to test locally or debug production issues. For fintech and banking developers, that usually means building custom setups and relying more on logs than friendly tooling.

Best Service Virtualization Tools: Detailed Comparison

Arti Jain — Sat, 23 Aug 2025 19:18:01 +0000

When you're building or testing an application that depends on other services—like APIs, databases, or third-party systems—you often hit a roadblock when those services are unavailable, slow, or incomplete. This is where service virtualization comes in. It helps you simulate those services so you can test and develop without being blocked.

Types of Service Virtualization

Before comparing tools, it helps to understand the different types of service virtualization. Not all tools focus on the same thing, and depending on your use case, one type may be more relevant than the others.

1. Database Virtualization

This refers to mocking or simulating databases at the binary protocol level. Tools in this category simulate how databases like MySQL or PostgreSQL respond. But in practice, this kind of virtualization is rarely needed. Setting up real databases—even containerized or in-memory ones, is straightforward and inexpensive these days. Because of that, database virtualization has limited value in modern software integrations and testing.

2. Messaging Queue Virtualization

This type simulates systems like Kafka, RabbitMQ, or AWS SQS. Messaging queues are often critical in distributed systems and microservice architectures. Virtualizing these helps teams test producers and consumers without needing the full infrastructure in place. This is more relevant than DB virtualization, especially in event-driven architectures.

3. Contract Virtualization

This is where most of the need lies today. It involves simulating service contracts like REST, SOAP, GraphQL, or gRPC. The mock not only replicates the endpoint structure but also includes behavior and test data. You can simulate errors, timeouts, stateful flows, and realistic payloads. Tools in this space allow teams to move fast, to test integrations, run golden path scenarios, and validate contracts. If you’re making a buying decision, contract virtualization is the most future-proof and widely adopted category to focus on.

Tools

There are quite a few tools that offer this, each with different capabilities. I will talk about these and walk through some of the best service virtualization tools available, compare how they work, and look at how easy they are to use.

1. Broadcom Service Virtualization (DevTest/Lisa)

https://www.broadcom.com/info/continuous-testing/devtest-portfolio-overview

Broadcom’s service virtualization platform is built for larger systems. It handles a wide range of protocols, including REST, SOAP, JDBC, MQ, and even mainframe services. It is fully on-premise, heavy weight. It comes with a learning curve reflects that there are certifications aroud this. It's flexible and has strong capabilities, but might be too complex or heavy if you're and SME. Teams that already rely on other Broadcom products might find it easier to integrate. Remember, this comes with consultancy cost, not just the product.

2. Beeceptor

https://beeceptor.com

Beeceptor is a no-code service virtualization platform. It focuses on HTTP-based APIs and supports both REST and SOAP. You can use it onpremise or in the cloud. It’s the only real-time platform, so you can inspect and debug traffic as it hits your endpoints. You can create stateful APIs that maintain data between requests, like a CRUD service. Beeceptor also supports OpenAPI-based contract mocking. You can upload a spec and it will generate mocks. This is AI powered and helps you auto-generate responses based on the given schema. Beeceptor is easy to start, and gives you great flexibility with their no-code template engine. Beeceptor comes with forever free plan.

3. Parasoft Virtualize

https://www.parasoft.com/products/parasoft-virtualize/

Parasoft Virtualize is a tool made for larger enterprise teams that need to simulate complex services. It supports various protocols-like REST, SOAP, JMS, MQ, FTP, JDBC, and others. You can use it on-premise, which is useful if you're in a company with strict data policies. Once it’s set up, it helps reduce test delays and manage service dependencies well. The setup can take time, as the UI is convoluted (and traditional) and might need a bit of learning and training.

4. ReadyAPI (SmartBear)

https://smartbear.com/product/ready-api/

ReadyAPI is designed mostly for API-level testing and mocking. It works well with REST, SOAP, GraphQL, and JDBC. It's easier to use compared to broader virtualization tools. It has a drag-and-drop interface, still a desktop based application. You can use it on-premise, which helps for internal projects. If your team is mostly working on web APIs and doesn’t need legacy protocol support, this could be a fit.

5. WireMock

https://wiremock.org/

WireMock is an open-source tool made for mocking REST APIs. It supports HTTP and HTTPS, and you can run it locally, inside Docker, or as a Java library. It’s good for simulating simple services and can be integrated into your unit tests or CI pipelines. Wiremock is mostly popular among Java architects, and mostly used in unit testing. However, it has newer capabilities for integration tests. It doesn’t support protocols like JMS or MQ. Great choice if you're working with REST APIs and want something lightweight and scriptable.

6. Mountebank

https://github.com/mountebank-testing/mountebank

Mountebank is another open-source option, and it works across platforms. It supports HTTP, HTTPS, TCP, and SMTP. You can run it on-premise, even as a CLI tool. You define “imposters” that simulate your real services. It’s flexible if you like working with config files or scripting. But like WireMock, it doesn’t support some of the enterprise protocols, so it’s suited for simpler & complex, both types of mocking scenarios. It works well for DevOps teams that want to automate their mocks. Not be a friendlier with QA.

7. Traffic Parrot

https://trafficparrot.com/

Traffic Parrot is a commercial tool aimed at teams working with microservices and message queues. It supports REST, SOAP, JMS, and IBM MQ. You can use it on-premise, which is handy for private systems. The interface is mostly code-driven, but you can script and automate mocks easily. It finds a middle ground between full-scale enterprise tools and open-source mocks. Some setup is needed, but it gives you flexibility with more protocol support than open-source tools. It works well if you're doing integration testing in a distributed system.

Summary

If you're working in a large enterprise with complex environments and protocols, have great budget to spend, pick Broadcom DevTest, or Parasoft Virtualize

If you're mostly dealing with APIs and want something simpler and easier to use, Beeceptor & ReadyAPI might make more sense. Beeceptor stands out for it's ease to setup, simulate stateful behavior, or test against contracts without writing code.