API Testing Services in India

Why Does a Green Integration Suite Still Break Your Consumers?

Here is the sequence almost every team recognises. Your service has an integration test suite. It runs on every commit. It is green. You ship on Tuesday afternoon. On Wednesday morning the mobile team files a bug saying a field came back null that has never been null before, and a partner emails to say their nightly sync failed with a parse error at 02:00.

Nothing in your pipeline was wrong. It was answering a different question. An integration suite normally exercises your service against fixtures your own team wrote, asserting the behaviour your own team expects. That proves internal consistency. It says nothing about whether the exact request your consumer sends still produces a response their deserialiser can read. The consumer, meanwhile, is testing against a stub that someone hand wrote nine months ago and has updated twice since. Both suites are green. Neither of them has ever seen the other side.

The breakages that come out of that gap are boringly consistent. A field is renamed and the old name stays in the docs. A type quietly changes from integer to string because an ORM column changed. An enum gains a value that a consumer's switch statement does not handle. A validation rule tightens and requests that used to pass start returning 422. An endpoint starts returning 200 with an empty array where it used to return 404, and a consumer's error handling silently stops firing. None of these are exotic bugs. They are all invisible to a suite that only ever talks to itself.

The cost lands unevenly, which is why it stays unfixed. Your team spends an hour. The consumer team spends a day, plus the meeting about why nobody warned them, plus the trust they no longer extend to your release notes. If the consumer is a paying customer integrating against a public API, the cost is a support queue and a churn conversation. If it is an internal team, the cost is that they start pinning to an old version and copying your data into their own store, which is how a distributed system quietly turns into a set of unreliable copies.

API testing is the layer that answers the question your integration suite does not: given everything that currently depends on this interface, is this change safe to release? That is a different job from clicking through a browser, and it needs different tools, different assertions and a different place in the pipeline.

Contract Testing with Pact, and What Consumer-Driven Really Means

Contract testing is the highest value work at this layer and the least understood. The phrase gets used for three different things, so it is worth being precise about the one that actually prevents outages.

How a consumer-driven contract test runs

The consumer team writes a test in their own suite that says: when I call GET /orders/1234 with this token, I expect a 200 with an object containing an id string, a status from this set, and a total that is a number. Pact runs that test against a local mock, and if the consumer code passes, it emits a pact file recording the interaction. That file is the contract. It is not a document somebody wrote. It is a byproduct of the consumer's own test, which is why it stays accurate.

The provider then replays every recorded interaction against a real running build of the provider service and asserts the responses satisfy the recorded expectations. That verification runs in the provider's pipeline. If a developer renames a field that any consumer relies on, their build fails before the merge, with the name of the consumer that would have broken.

The broker, can-i-deploy and why the gate matters

Contracts are stored in a broker, either the open source Pact Broker or the hosted PactFlow. The broker knows which versions of which consumers have been verified against which provider versions. The Pact CLI then gives you can-i-deploy, a command that answers whether a specific version is safe to release given everything currently deployed. Without that gate, you have contract tests. With it, you have a release decision that is automatic and does not depend on somebody remembering.

Provider states, the part teams get wrong

Every interaction assumes the provider is in some state: an order with id 1234 exists and is shipped. Pact expresses that as a provider state, and the provider must implement a hook that puts the system into it before replay. Teams frequently implement those hooks by inserting rows straight into the database, which is fast and wrong, because it lets the test pass while the real creation path is broken. We implement provider states through the service's own API or domain layer wherever the runtime permits.

When Pact is the wrong tool

Pact assumes you can influence the consumer. For a public API with thousands of anonymous integrators, that assumption fails, and you should be running schema based compatibility checks plus recorded traffic replay instead. Pact is also poorly suited to testing behaviour that depends on real data volumes or on a third party you do not control. And it is genuine work for both teams. If the consumer team will not run the tooling, the contract will rot, and a rotted contract is worse than none because it gives false confidence.

Bidirectional contracts and Spring Cloud Contract

Where a consumer will not adopt Pact, bidirectional contract testing compares a consumer's recorded expectations against the provider's own OpenAPI document, which is weaker but needs far less from the provider. In JVM estates, Spring Cloud Contract is often the pragmatic choice because it generates provider tests and consumer stubs from a single contract definition and fits existing Maven and Gradle habits. We pick per pair rather than mandating one tool across an estate.

Versioning and Backward Compatibility Testing

Versioning policy is usually written once and then enforced by hope. Backward compatibility testing is what turns the policy into something the pipeline checks.

What actually counts as a breaking change

The list is longer than most policies admit. Removing a field or an endpoint is obvious. So is renaming one. Less obvious: narrowing a type, adding a required request field, tightening validation on an existing field, removing a value from an enum, changing a status code for an existing condition, changing the default sort order of a collection, reducing a page size limit, and changing the semantics of a field while keeping its name and type. That last one is the worst because no automated check will catch it. We write it down explicitly with your team, then encode everything mechanically detectable.

Replaying old clients against the new build

The most convincing compatibility test is traffic. We capture a representative sample of real requests, scrub anything sensitive, and replay it against the release candidate, comparing responses to the recorded baseline with an allowlist of expected differences such as timestamps and generated identifiers. This catches semantic changes that schema comparison cannot, because it compares what the API did rather than what it declared.

Deprecation, Sunset and the paperwork of removal

Removing anything from a public API is a process, not a commit. The mechanics worth testing are that a deprecated endpoint still works, that it emits the deprecation signalling your policy specifies, and that it appears in the documentation as deprecated. The Sunset HTTP header defined in RFC 8594 gives you a machine readable removal date, and a Deprecation response header field is the companion signal in common use. Tests assert that both are present on the routes your policy says are deprecated, and that they disappear when the route is finally removed. Consult your own counsel on any contractual notice obligations to customers, which are a separate matter from the technical signalling.

Compatibility in protobuf and GraphQL

For gRPC, compatibility is a property of the .proto file, and it is enforceable. Field numbers must never be reused, required semantics must not tighten, and buf breaking will diff a schema against a baseline in CI and fail the build on a violation. For GraphQL, additive change is generally safe and removal is not, so the check is a schema diff against the previously published version combined with field usage data. Apollo schema checks and GraphQL Inspector both do this. If you have usage telemetry, a field with zero queries in ninety days is safe to remove and a field with one query from one important client is not, and that decision should be made from data rather than from a hunch.

Test Data, Idempotency and Suites That Can Run Twice

The most common reason an API suite becomes untrusted is not a bug in the API. It is that the suite passes on a clean database and fails on the second run, so people start rerunning it until it goes green, and at that point it has stopped being a test.

Data that a second run does not poison

Shared seed data is the usual culprit. A test creates a user with a fixed email address, the next run hits a uniqueness constraint, and the failure looks like a bug in registration. Generating identifiers per run fixes it. So does isolating by tenant, which has the useful side effect of exercising your tenant scoping. For read-heavy suites, a small deterministic seed that no test mutates plus per test generated data for anything written is the pattern that has held up best for us.

Idempotency keys and duplicate delivery

Any endpoint that moves money, sends a message or creates a resource needs to answer what happens when the same request arrives twice, because at some point it will. Networks retry, clients retry, queues deliver more than once. If your API accepts an idempotency key, the tests must cover the same key with the same body returning the original result, the same key with a different body being rejected rather than silently overwriting, and concurrent requests with the same key not creating two records. That third case needs genuine concurrency in the test, not two sequential calls, and it is the one that finds real defects.

Webhooks and asynchronous completion

Half of what modern APIs do finishes later. Testing that properly means a receiver the suite controls, assertions on payload shape and signature verification, and explicit coverage of retry behaviour and out of order delivery. It also means killing arbitrary sleeps, which are the main source of flakiness in async tests. Polling with a timeout, or a callback the test can await, keeps the suite honest and fast.

Cleanup, and when not to bother

Cleanup after every test is tidy and slow, and cleanup code that fails mid-run leaves worse state than no cleanup at all. Against a disposable database, dropping the whole thing at the end of the run is simpler and more reliable. Against a shared environment where that is not an option, tag every created record with the run identifier and sweep by tag on a schedule, so a crashed run does not block the next one.

Rate Limits, Errors and the Unhappy Paths

Error behaviour is part of your interface whether you documented it or not. Consumers write code against it. When it changes, their code breaks in exactly the same way a renamed field breaks it, with the difference that nobody noticed because errors are rarely in the test suite.

Rate limits, 429 and Retry-After

Three things need asserting. That the limit triggers where the documentation says it does. That the response carries the headers a client needs to behave well, which usually means Retry-After and whatever limit and remaining headers you publish. And that the limit is scoped correctly, so one tenant exhausting their quota does not throttle another. That last case has taken down more than one shared API, and it is trivially testable once you think to test it.

Error bodies are a contract

If your API returns a machine readable error shape, it needs the same schema discipline as a success response. RFC 9457 defines the problem details format for HTTP APIs, superseding RFC 7807, and adopting it means clients can parse errors generically rather than string matching on messages. Whether or not you adopt it, tests should assert that the error type or code for a given condition is stable, because consumers branch on those values. Changing an error code is a breaking change even though nothing in your schema moved.

Timeouts, retries and amplification

A dependency stops responding. What does your API do? Tests using a mock that simply never replies establish whether you time out at a sensible boundary or hold the connection until the load balancer kills it. If you retry, cover the case where retries stack across layers: a client retrying three times against a gateway retrying three times against a service retrying three times is twenty seven requests to a dependency that is already struggling, which is how a slow dependency becomes an outage.

Partial failure and pagination

Batch endpoints need a defined answer for what happens when item seven of ten fails, and it should be documented and tested rather than emergent. Pagination needs coverage at the boundaries: an empty result set, a single page exactly at the limit, a cursor from a deleted record, a page size above the maximum, and a negative offset. These are five minutes of work each and they turn up broken behaviour on most APIs we test.

The Tools We Use, and When Each One Is Wrong

We do not arrive with a preferred stack to install. The right choice depends on what your engineers already read and maintain, because a suite in a language your team does not use is a suite your team will not fix.

Postman and Newman

Excellent for exploration and for handing a working example to a partner. Newman runs a collection in CI, which makes it a reasonable smoke test lane. It is the wrong choice as the backbone of a large regression suite: assertions live in JavaScript embedded in JSON, which reviews badly and refactors worse, and collections tend to accumulate duplicated setup that nobody dares delete.

REST Assured

For JVM teams, this is usually the right answer for the main suite. Tests sit in the same repository and the same build as the service, engineers review them like any other Java or Kotlin code, and JSON path assertions are compact. It is the wrong choice for a team with no JVM presence, where it imports a toolchain for no benefit.

Karate

Tests are written in a readable domain specific language, so people who are not primarily developers can contribute, and it has useful built in support for parallel execution and for stubbing. The trade-off is real: you are learning a syntax that exists only inside one tool rather than writing in your own language, and complex logic gets awkward. Good fit for a dedicated QA function, weaker for a team where developers own the tests.

Pact

The tool for consumer-driven contracts, with client libraries across JVM, JavaScript, Python, .NET, Go and Ruby. Worth the setup once you have multiple teams releasing independently. Not worth it when the consumer is anonymous or unwilling, or when you have a single team shipping everything together.

Schemathesis

The fastest way to find undocumented behaviour and unhandled inputs from an existing OpenAPI or GraphQL schema. Almost free to run, and it needs a good schema to be useful. Against a stale or permissive document it will find little, which is itself a useful diagnostic.

k6

For API level load and soak work, scripted in JavaScript and comfortable in CI. We use it here for the questions that belong to the API layer, such as whether rate limiting holds under concurrency and whether latency degrades gracefully as request volume rises. Full performance engineering, capacity modelling and profiling under sustained load is a separate discipline and a separate engagement.

WireMock and Prism

WireMock for stubbing dependencies with fault injection and response templating. Prism for standing up a mock server directly from an OpenAPI document, which is particularly useful when a consumer needs to start before the provider is built. Both drift if nothing keeps them aligned with reality, which is the argument for deriving them from contracts or schemas.

The language native option

Often the best answer is no new framework. pytest with httpx, Jest or Vitest with supertest, xUnit with HttpClient. The suite lives with the code, runs with one command, and needs no separate onboarding. We reach for this first for teams who own their own quality and want the tests inside the service repository.

Four Situations We Get Called Into

These are the patterns behind most enquiries at this layer. Details differ. The shape rarely does.

The platform team that keeps breaking the mobile app

A backend team of eight ships several times a week. A mobile team of four ships every two weeks through an app store review. Every few sprints the backend changes something the app depended on, and because the app in the field cannot be updated instantly, the breakage sits in users' hands for days. The backend team is not careless. They simply have no mechanism that tells them what the shipped app relies on. The fix is a contract from the mobile client, verified in the backend pipeline, plus recorded traffic from the two previous app versions replayed against every release candidate. After that, the breaking change is caught on the branch, and the conversation moves from apology to design.

The public API where every release is a support incident

A company with a documented public API and a few hundred integrators. Nobody knows who uses which endpoint. Every release is followed by a nervous week and a handful of tickets from customers whose integration stopped working. Pact does not apply because the consumers are anonymous and unreachable. What does apply: strict schema validation with additionalProperties closed, an automated breaking change diff of the OpenAPI document against the published version, replay of sampled production traffic, and usage telemetry per endpoint so removal decisions are made from evidence. The nervous week becomes a routine deploy.

The migration where the new service must behave exactly like the old one

A monolith endpoint is being reimplemented in a new service. The requirement is that consumers notice nothing. Here the highest value test is a comparison harness: replay identical requests against old and new, diff the responses field by field with an explicit allowlist for known differences, and run it over a large sample of real traffic rather than a handful of hand-picked cases. It reliably finds the things a specification never captured, such as a field that has always been returned in insertion order, or an error case that returned 400 in one path and 422 in another. Teams that skip this step usually find those behaviours after cutover, from a customer.

The estate with sixty services and no idea what talks to what

Microservices, several teams, and a dependency graph that exists only in people's heads. Nobody can say with confidence what a change to a given service affects, so every change gets tested by deploying to a shared environment and waiting. The starting move is not writing tests. It is producing the graph from traffic data, then contract testing the highest traffic pairs first and expanding by risk. Trying to contract test sixty services at once is how this work gets abandoned in month three.

What Goes Wrong, and How We Handle It

The honest section. These are the things that actually derail this work, and what we do when they show up.

The spec turns out to be fiction

Common enough that we plan for it. The first week becomes reconciliation: drive the real endpoints, diff observed behaviour against the document, produce a list of divergences and let your team decide per item which side is correct. It delays the first tests by days, not weeks, and skipping it means building on sand.

There is no environment worth testing against

Sometimes the blocker is not testing at all. Staging is stale, the seed data is from 2021, and the third party sandbox has been broken since an upgrade. When that is the situation we say so immediately, because writing tests against an environment nobody trusts produces results nobody trusts. The usual path is containerised dependencies for the pull request lane so progress is not gated on infrastructure, with the shared environment work sequenced separately.

The consumer team will not adopt contract testing

Pact needs work from both sides. If the consumer team has no capacity or no interest, the contract will not stay accurate, and a stale contract is worse than none. Rather than pushing it, we move to provider-side compatibility checking, schema diffs and traffic replay, which is weaker but needs nothing from them. We raise this in the first fortnight, because discovering it in month two wastes everyone's time.

Auth is faked in the test environment

A surprising number of test environments accept any bearer token or run with authorisation middleware disabled for convenience. That makes the entire authorisation matrix meaningless while looking green. When we find it, it becomes a blocker to be fixed rather than a caveat in a report, because it is also usually a sign that nothing has ever verified those checks anywhere.

The suite grows into a second end-to-end suite

The slow drift where API tests start orchestrating six calls to set up a scenario, then assert on a business outcome, then take twelve minutes and start failing for unrelated reasons. We push back on it in review. If a test needs a long orchestration, it usually belongs in a nightly lane or in a different layer entirely. Keeping the API suite about the interface is what keeps it fast enough to be trusted.

Continuity of the people doing the work

People change jobs, in India and everywhere else. The mitigations are structural rather than promissory: at least two engineers familiar with each area, everything in your repository under your review process, no knowledge held only in someone's head, and written handover as a normal part of the work rather than an exit activity. Notice, replacement and handover terms are set out in the MSA before work starts, and we will not quote you a number on a web page that we have not agreed with you.

Where This Sits Alongside Our Other Work

API testing rarely arrives on its own. If the underlying problem is that the API itself needs designing or rebuilding rather than testing, that work sits with our API development services, and the tests are better written alongside the endpoints than bolted on afterwards. Where the interfaces being tested are the seams between newly split services, the contract boundaries and the microservices architecture constrain each other and are worth deciding together.

If your wider quality problem is broader than the interface layer, including manual coverage, release process and test strategy across the whole product, start with our QA and testing services and let the API layer be one workstream inside it. The tests only pay for themselves once they run automatically on every change, which is why this work pairs naturally with CI/CD pipeline services in India, especially where lane design and pipeline duration are already a problem. And if what you need is engineers inside your team rather than a scoped engagement, hiring dedicated Python developers in India or Java developers in India gives you the same skill set on a different commercial shape.