REST, GraphQL, contract testing, security, and CI/CD integration — with real code examples

APIs are the nervous system of modern SaaS applications. They connect your frontend to your backend, your service to third-party integrations, your microservices to each other. When APIs work correctly, users don’t notice them. When they fail, everything fails.

API testing is also one of the highest-ROI testing investments available. API tests are faster than UI tests, more stable, easier to maintain, and closer to the actual business logic. A well-structured API test suite catches the majority of functional regressions before they reach the UI layer — where they’re more expensive to find and fix.

This guide covers the full API testing landscape for modern SaaS: REST and GraphQL strategies, contract testing with Pact, performance and security testing, CI/CD integration, and a real fintech example with working code.

REST vs GraphQL testing strategies

REST and GraphQL APIs have fundamentally different architectures, which means they require different testing approaches. Understanding the differences helps you build a test strategy that actually reflects how your API works.

Aspect	REST API Testing	GraphQL Testing
Endpoint structure	Multiple endpoints, each with fixed schema	Single endpoint, flexible queries
Test scope	Test each endpoint independently	Test query/mutation combinations
Response validation	Fixed response structure per endpoint	Variable structure based on query
Error handling	HTTP status codes (404, 500, etc.)	Always 200, errors in response body
Performance testing	Load test individual endpoints	Test query complexity and N+1 issues
Contract testing	OpenAPI/Swagger specs	Schema introspection
Common tools	Postman, RestAssured, k6	Apollo Studio, GraphQL Inspector

REST API testing strategy

REST APIs organize functionality around resources and HTTP methods. A well-structured REST test suite tests each endpoint across its full range of scenarios:

• Happy path: valid request, expected response, correct HTTP status code
• Authentication: requests with valid token, expired token, missing token, invalid token
• Authorization: requests from users with correct permissions, insufficient permissions, no permissions
• Validation: requests with missing required fields, invalid field types, out-of-range values, malformed JSON
• Edge cases: empty collections, maximum payload sizes, special characters in string fields
• Error responses: verify error messages are helpful without exposing sensitive system details

The key insight for REST testing: test the contract, not the implementation. Your tests should verify what the API promises to do, not how it does it internally. This makes tests resilient to refactoring and more meaningful as documentation.

GraphQL testing strategy

GraphQL presents different testing challenges. With a single endpoint and flexible query structure, traditional endpoint-by-endpoint testing doesn’t map directly.

Focus your GraphQL testing on:

• Query validation: test that valid queries return expected data, invalid queries return meaningful errors
• Mutation testing: verify that mutations change data correctly and return accurate responses
• Authorization at the field level: GraphQL allows fine-grained authorization — verify that users can’t access fields they shouldn’t see even within queries they’re authorized to make
• N+1 query detection: GraphQL’s flexibility can create performance problems when resolvers make database queries for each item in a list. Test with data sets large enough to surface N+1 issues.
• Schema testing: use GraphQL’s introspection to verify the schema matches expectations — particularly useful when the schema is generated from code
• Error handling: unlike REST, GraphQL always returns HTTP 200. Test that errors are returned in the errors field of the response, not swallowed silently

Contract testing with Pact

Contract testing is the most underused API testing practice and one of the most valuable — particularly for teams with microservices architectures or multiple teams working on connected services.

The problem it solves: two services are developed and tested independently. They work in isolation. They break when integrated — because the team building the consumer made assumptions about the provider’s API that aren’t true, or the provider changed their API in a way that broke existing consumers.

Contract testing makes these assumptions explicit. A consumer writes tests that define what it expects from the provider. These expectations become a contract. The provider runs the contract as part of their test suite, verifying they still meet the consumer’s expectations. When the provider breaks the contract, it fails immediately — not in integration testing or production.

Pact in practice

Pact is the most widely adopted contract testing framework. Here’s a minimal consumer-side Pact test in JavaScript that defines what a payment service expects from a user service:

const { Pact } = require(‘@pact-foundation/pact’);

const { fetchUser } = require(‘./userClient’);

const provider = new Pact({

  consumer: ‘PaymentService’,

  provider: ‘UserService’,

  port: 8080,

});

describe(‘User Service contract’, () => {

  before(() => provider.setup());

  after(() => provider.finalize());

  it(‘returns user payment details’, async () => {

    await provider.addInteraction({

      state: ‘user 123 exists with payment method’,

      uponReceiving: ‘a request for user payment details’,

      withRequest: {

        method: ‘GET’,

        path: ‘/users/123/payment’,

        headers: { Authorization: ‘Bearer token’ }

      },

      willRespondWith: {

        status: 200,

        body: {

          userId: ‘123’,

          paymentMethodType: ‘card’,

          last4: ‘4242’

        }

      }

    });

    const user = await fetchUser(‘123’);

    expect(user.paymentMethodType).to.equal(‘card’);

  });

});

This test generates a Pact file — a JSON contract — that the UserService team runs against their actual implementation. If the UserService changes the response structure, the Pact verification fails and the breaking change is caught before deployment.

Pact Broker (or PactFlow, the managed version) stores contracts and tracks which provider versions are compatible with which consumer versions. This becomes the source of truth for safe deployment decisions in a microservices environment.

Performance testing APIs

API performance testing verifies that your endpoints meet response time and throughput requirements under realistic load. Unlike UI performance testing, API performance testing is fast to set up and highly precise — you control exactly what requests are sent and can measure exactly how the system responds.

k6: the modern default

k6 has become the default recommendation for API load testing in 2026. It’s developer-friendly (JavaScript-based), runs efficiently without a GUI, integrates well with CI/CD pipelines, and has excellent cloud execution options for high-load tests.

Here’s a k6 script that load tests a payment API endpoint with 50 virtual users over 30 seconds:

import http from ‘k6/http’;

import { check, sleep } from ‘k6’;

export const options = {

  vus: 50,

  duration: ’30s’,

  thresholds: {

    http_req_duration: [‘p(95)<500’],

    http_req_failed: [‘rate<0.01’],

  },

};

export default function () {

  const payload = JSON.stringify({

    amount: 1000,

    currency: ‘USD’,

    userId: ‘test-user-001’,

  });

  const params = {

    headers: {

      ‘Content-Type’: ‘application/json’,

      Authorization: `Bearer ${__ENV.API_TOKEN}`,

    },

  };

  const response = http.post(

    ‘https://api.yoursaas.com/payments’,

    payload,

    params

  );

  check(response, {

    ‘status is 200’: (r) => r.status === 200,

    ‘response time OK’: (r) => r.timings.duration < 500,

    ‘transaction ID present’: (r) => JSON.parse(r.body).transactionId !== undefined,

  });

  sleep(1);

}

The thresholds block is where quality gates live: 95th percentile response time under 500ms, error rate below 1%. If either threshold is breached, k6 exits with a non-zero status code — which causes a CI pipeline stage to fail automatically.

JMeter for complex scenarios

Apache JMeter remains relevant for complex load testing scenarios — particularly when you need a GUI for test design, when you’re testing non-HTTP protocols (JDBC, LDAP, FTP), or when your organization has existing JMeter expertise and infrastructure. JMeter is more powerful than k6 for complex test plans but harder to integrate into code-first CI/CD pipelines.

Security testing for APIs

API security testing is different from application security testing — it focuses on the API layer specifically, where different attack vectors apply.

Authentication testing

Every authenticated API endpoint needs to be tested against the full range of authentication scenarios:

• Valid token: request succeeds
• Expired token: returns 401, not 500
• Invalid token signature: returns 401
• Missing Authorization header: returns 401
• Token with insufficient scope: returns 403
• Token belonging to deleted or suspended user: returns 401 or 403

These scenarios are easy to test systematically with a parameterized test approach — one test function, multiple token scenarios as inputs. Teams that test these scenarios ad hoc tend to have gaps; teams that test them systematically don’t.

Authorization testing

Authorization bugs — where one user can access another user’s data — are among the most serious API security failures and among the most commonly missed in testing. The attack pattern is simple: take a valid API request, change the resource ID in the URL or request body, and see if you get data back.

Test authorization systematically by verifying that every endpoint that returns user-specific data correctly rejects requests from users who don’t own that data. This is often called IDOR (Insecure Direct Object Reference) testing and should be part of your standard API test suite, not just penetration testing.

Here’s a RestAssured example that tests IDOR on a transaction endpoint — verifying that User A cannot access User B’s transactions:

// RestAssured IDOR test example

String userAToken = authenticate(‘us***@*****le.com‘, ‘passwordA’);

String userBToken = authenticate(‘us***@*****le.com‘, ‘passwordB’);

// Get a transaction ID that belongs to User B

String userBTransactionId = getUserTransaction(userBToken);

// Attempt to access User B’s transaction with User A’s token

given()

  .header(‘Authorization’, ‘Bearer ‘ + userAToken)

.when()

  .get(‘/api/transactions/’ + userBTransactionId)

.then()

  .statusCode(403)  // Must return Forbidden, not 200

  .body(‘error’, equalTo(‘Access denied’));

This test should be part of every API test suite that handles user-owned resources. A response of 200 from this test is a critical security vulnerability.

Rate limiting

APIs without rate limiting are vulnerable to abuse — either accidental (a client with a bug making thousands of requests) or intentional (denial of service, credential stuffing). Test that your rate limiting works as documented: verify the limit triggers at the right threshold, returns the correct HTTP status (429), includes appropriate headers (Retry-After), and resets after the specified time window.

CI/CD integration for API tests

API tests should run automatically in your CI/CD pipeline. The integration is straightforward because API tests don’t require browser infrastructure or complex setup — they’re just HTTP requests against a running service.

Recommended pipeline structure for API tests:

• Unit tests → integration tests (including API tests against a local service) → E2E tests (including API tests against staging)
• API contract tests run as part of both consumer and provider test suites, triggered on every change to either service
• API performance tests run against staging before every production deployment, with thresholds enforced as quality gates
• API security scans (OWASP ZAP, Burp Suite in automated mode) run weekly against staging as a scheduled pipeline

The key to effective CI/CD integration for API tests: treat failing API tests as failing builds. A performance threshold breach or a contract violation that doesn’t block deployment provides no value — it’s just noise.

Real-world example: API testing for fintech

A fintech startup building a payment processing platform came to TestMatick with a common problem: they had functional tests for their payment API, but production incidents kept occurring at the integration points — between their payment service and the bank APIs they connected to, and between their API and the merchant clients that used it.

The root cause: their testing verified that their API worked in isolation, but didn’t verify the contracts between their service and its dependencies. When a bank API changed a response field, TestMatick’s team built a contract testing layer using Pact that defined the exact format their system expected from each bank integration. When a bank updated their API, the Pact verification caught the breaking change before it reached production — twice in the first three months.

For the merchant-facing API, the team built a comprehensive security test suite covering 47 distinct security scenarios: authentication edge cases, IDOR testing across all transaction and account endpoints, rate limiting verification, and injection testing on all input fields. Two high-severity vulnerabilities were found and fixed before the API went to production — an IDOR vulnerability on the transaction history endpoint and a missing rate limit on the authentication endpoint that would have allowed credential stuffing attacks.

Performance testing with k6 revealed that their transaction history endpoint degraded significantly under load when users had more than 10,000 transactions. In development and staging with small datasets, response times were 180ms. Under load with realistic data volumes — simulating merchant accounts with 18 months of transaction history — response times exceeded 3.4 seconds at the 95th percentile. A composite database index on the userId and createdAt fields reduced this to 210ms under the same load conditions.

The combined result: zero production API incidents in the six months following implementation, compared to four significant incidents in the six months prior — including one that caused a 4-hour payment processing outage. The investment in contract testing, security testing, and performance testing under realistic conditions paid back in avoided incidents within the first quarter.

The API testing mindset

The teams that get API testing right share a common perspective: they treat APIs as products, not just technical interfaces. An API that works correctly but fails under load, exposes user data through IDOR vulnerabilities, or breaks silently when an upstream service changes its contract is not a well-tested API — it’s a functional API with undetected problems.

The practices in this guide — contract testing, security testing, performance testing under realistic conditions — are not advanced techniques reserved for large engineering teams. They’re the baseline for any SaaS product where the API layer handles user data, processes payments, or powers business-critical functionality. The fintech example above isn’t unusual. It’s representative of what happens when API testing is limited to happy-path functional verification and misses the integration, security, and performance dimensions that production failures actually come from.

Start with the fundamentals: systematic authentication and authorization testing, a contract testing layer for your key service integrations, and performance thresholds enforced as CI quality gates. These three practices alone catch the majority of API failures before they reach production.

Frequently Asked Questions

Should we use Postman or code-based tools for API testing?

Both have legitimate uses. Postman is excellent for exploratory API testing, documentation, and manual verification during development. Code-based tools (RestAssured, k6, Pact) are better for automated testing in CI/CD pipelines — they version-control alongside your codebase, integrate with your build system, and don’t require a GUI to run. Most mature API testing setups use both: Postman for development-time exploration, code-based tools for automated pipeline testing.

How do we test APIs that depend on external services?

Mock the external dependencies. Tools like WireMock, Mockoon, or simple in-code mocks let you simulate external API responses without making real calls. This makes tests faster, more reliable, and runnable without network access. Contract tests (Pact) then verify that your mocks accurately represent the real external service — closing the gap between mocked tests and production behavior.

What’s the right balance between API tests and UI tests?

API tests should cover the majority of your functional scenarios. They’re faster, more stable, and closer to the business logic. UI tests should cover the user journeys that can’t be validated at the API layer — visual rendering, user interaction flows, multi-step processes that span multiple API calls. A common target: 70% API tests, 20% UI tests, 10% specialized tests. This ratio produces faster pipelines and more stable test suites than UI-heavy approaches.

Need API testing for your SaaS product?

TestMatick tests REST and GraphQL APIs across functional, performance, security, and contract testing dimensions. If your API layer is where production incidents keep happening — or where you want to prevent them — that’s a conversation worth having.

-> Book API Testing Consultation — testmatick.com