Noise & Secret Management in API Tests

Noise is any field in a captured API request or response that changes between runs for reasons unrelated to correctness — timestamps, UUIDs, session tokens, pagination cursors. Keploy automatically detects these patterns at capture time and normalizes them during replay so deterministic assertions do not produce flaky failures. Secrets and PII are masked at capture so the values never persist to disk, with built-in defaults for GDPR, HIPAA, and PCI DSS compliance.

This page explains how Keploy's deterministic replay engine handles the two hardest problems in traffic-based testing: non-deterministic data that causes false failures, and secrets that should never appear in committed test fixtures.

What is noise in captured API traffic?

Every recorded HTTP interaction contains two kinds of fields: fields that are determined by your application logic (a user's name, a product's price, an order's line items) and fields that change every time a request is processed regardless of what your code is doing. The second category is noise.

Common sources of noise in HTTP APIs:

Timestamps. Every response with a createdAt, updatedAt, or Date header contains a new value on every replay. Comparing these literally guarantees a false failure on the second run.
UUIDs and auto-incrementing IDs. Database-generated IDs are not stable across runs unless the database is reset to a known state between captures — and even then, any feature that assigns an ID from an external service (Stripe customer ID, auth provider user ID) breaks the contract.
Session tokens and CSRF tokens. These are scoped to the current user session by design. A captured login response contains a token that will never be valid again.
Pagination cursors. Cursors encode server-side position and often include a timestamp or hash, so they change on every run.
Request-scoped trace IDs. Distributed tracing frameworks (OpenTelemetry, Jaeger) attach a unique trace ID to each request. That ID is logged and sometimes echoed back in response headers.
Rate-limit metadata. X-RateLimit-Remaining and Retry-After headers change as the service processes traffic.

A replay-based testing tool that treats all these fields as part of the assertion surface will produce tests that fail on every run. Flakiness is the default state — which is why traffic-based testing did not take off until the noise problem was solved.

How Keploy's deterministic replay engine handles noise

Keploy auto-detects the common noise patterns at capture time so most applications work out of the box with no configuration. The detection runs in two passes.

Pass 1: Pattern-based detection

Keploy scans every string field in the captured request and response bodies and headers for well-known formats:

ISO-8601 timestamps (2026-04-14T10:00:00Z)
Unix epoch seconds and milliseconds
UUID v1 through v5 (550e8400-e29b-41d4-a716-446655440000)
MongoDB ObjectId (24 hex characters)
Auto-incrementing positive integers used as IDs
JWT tokens (three dot-separated base64 segments)
Bearer tokens in Authorization headers

Any field matching one of these patterns is marked as noise in the generated test YAML. During replay, the field is compared with a structural matcher: a timestamp field is valid as long as the replayed response also contains a valid timestamp in the same format; a UUID field is valid as long as the replayed response contains a valid UUID of the same version.

Pass 2: User configuration

Application-specific noise (internal order IDs, request correlation tokens, domain-specific checksums) is not auto-detected. Those fields are marked via keploy.yaml:

# keploy.yaml
noise:
  global:
    body:
      - "$.data.orderId"
      - "$.data.correlationId"
      - "$.metadata.checksum"
    header:
      - "X-Request-Id"
      - "X-Trace-Id"
      - "X-RateLimit-Remaining"

Rules can also be scoped to a single test case by adding a noise block inside the generated YAML file. This is the right choice when a field is noise only in one specific flow (for example, an admin operation might return a request timestamp that matters for auditing and should be asserted, while the same field in a customer-facing flow is irrelevant).

Secret and PII masking

Noise detection determines what Keploy ignores during comparison. Masking determines what Keploy writes to disk in the first place. The two are different concerns — a timestamp is noise but does not need to be masked; a Stripe secret key is both noise and must never persist to disk.

Keploy masks values matching known secret patterns at capture time, before any write to the keploy/ directory:

Bearer tokens in Authorization headers
Cookie values (stored as opaque placeholders scoped by cookie name)
Stripe API keys (sk_live_..., sk_test_...)
AWS access and secret keys (patterns from the IAM guidance)
GitHub PATs (ghp_...) and OAuth tokens
JWTs (full token redacted; header can optionally be preserved)
PCI DSS: credit card numbers (Luhn-checked) and CVVs

For application-specific PII, add fields to the noise.global.body section with a redact: true flag:

# keploy.yaml
noise:
  global:
    body:
      - path: "$.user.email"
        redact: true
      - path: "$.user.phoneNumber"
        redact: true
      - path: "$.patient.ssn"
        redact: true
      - path: "$.patient.diagnosis"
        redact: true

Masked fields appear in the committed test YAML as [REDACTED] placeholders. During replay, Keploy treats them as structural matchers (any value of the same type passes). The original value is never touched after the initial in-memory redaction and never persists to disk, committed history, or CI logs.

Compliance posture: GDPR, HIPAA, PCI DSS

Keploy does not make a regulatory claim — compliance is your responsibility based on how you configure and operate the tool. What Keploy provides is the set of primitives that make compliant replay-based testing feasible.

GDPR

Email addresses, user names, IP addresses, and any field configured in redact are masked at capture time. Test fixtures committed to git contain no personal data from production users.

HIPAA

Protected health information fields (patient ID, diagnosis, prescription, insurance number) can be added to the redaction list and are masked before any disk write. Keploy can run inside a BAA-governed environment for capture.

PCI DSS

Card numbers matched by Luhn checking and CVVs are auto-redacted. For custom payment fields (bank account numbers, routing numbers, international IBAN), add to the user configuration.

How Keploy compares to WireMock and Hoverfly

WireMock and Hoverfly are the two most widely used recording-proxy tools for API testing. Both let you capture HTTP interactions and replay them as mocks, and both support request matching via regex patterns. Neither auto-detects noise.

Capability	Keploy	WireMock	Hoverfly
Auto-detect timestamps	Yes (ISO-8601, epoch)	Manual regex	Manual templates
Auto-detect UUIDs	Yes (v1-v5)	Manual regex	Manual templates
Auto-mask Bearer tokens	Yes	No	No
Auto-mask Stripe/AWS/GitHub keys	Yes	No	No
Luhn-checked card redaction	Yes	No	No
Capture at kernel level (no SDK)	Yes (eBPF)	Proxy or Java SDK	Proxy

For simple recorded mocks where you can tolerate writing regex matchers by hand, WireMock and Hoverfly are sufficient. For full regression suites where every non-deterministic field would otherwise need manual handling, and for applications that must meet compliance requirements on committed test fixtures, Keploy eliminates the bulk of that work through auto-detection.

Frequently asked questions

Noise is any field in a captured HTTP request or response that changes between runs for reasons unrelated to your code's correctness. The most common sources are timestamps (Date headers, createdAt fields), UUIDs and auto-incrementing IDs, session tokens, CSRF tokens, pagination cursors, request-scoped trace IDs, and rate-limit remaining counters. If a replay-based test asserts on these fields literally, every run will fail even when the service is behaving correctly. Keploy's noise filter normalizes these values during capture and replay so assertions focus on the fields that actually matter.

At capture time, Keploy marks fields matching well-known time and ID patterns (ISO-8601, Unix epoch, UUID v1-v5, 24-character ObjectIds) as noise by default. During replay, those fields are compared with structural matchers instead of literal values — a timestamp is accepted as long as it is a valid timestamp of the same format; a UUID is accepted as long as it is a valid UUID; an auto-incrementing ID is accepted as long as it is a positive integer. This behavior is configurable per field via the keploy.yaml config file.

Yes. Keploy has two layers of secret handling. The first is automatic redaction of fields matching common secret patterns: Bearer tokens in Authorization headers, cookie values, API keys matching common vendor formats (Stripe, AWS, GitHub), and JWTs. The second is user-defined masking via the keploy.yaml `noise.global.body` and `noise.global.header` sections where any JSONPath or header name can be marked redacted. Redacted fields are stored as opaque placeholders in the test YAML files — the original value never persists to disk.

Keploy is the infrastructure, not the compliance framework — but it provides the primitives needed to run compliant test suites. For GDPR, the redaction layer ensures personal data (email addresses, user names, IP addresses when configured) never appears in stored test fixtures. For HIPAA, protected health information fields can be added to the redaction list and are masked at capture time before any disk write. For PCI DSS, payment card numbers and CVVs matched by Luhn-checking patterns are automatically redacted. Enterprise customers receive a compliance guide covering how each regulation's requirements map to Keploy's noise and secret configuration.

Yes. The keploy.yaml `noise` section accepts both global and per-test-case rules. Global rules apply to every recorded test; per-test rules scope to a single captured interaction. Each rule takes a JSONPath (for request and response bodies) or a header name (for headers), and an action: noise (ignore during comparison), redact (mask value on disk), or assert (compare literally — used to override a field that would otherwise be caught by an automatic noise matcher). This covers application-specific things like internal order IDs, checksums, and request correlation tokens that Keploy does not auto-detect.

Mocks replace an entire dependency call with a canned response. Noise filtering keeps the real captured response intact but loosens the comparison so non-deterministic fields do not cause false failures. A test that exercises a payment gateway uses a mock (the recorded gateway response) AND a noise filter (so the gateway's session token changing between runs does not fail the test). The two mechanisms are orthogonal: Keploy generates both automatically from the same traffic capture.

WireMock and Hoverfly are recording proxies that save HTTP interactions as JSON stubs. Both support request matching via regex and placeholder substitution, but neither auto-detects noise patterns — you have to write regex matchers by hand for every field that might vary. Keploy captures at the kernel level (eBPF), auto-detects the common noise patterns listed above without configuration, and generates deterministic replay assertions on the first capture. For simple recorded mocks, WireMock is sufficient; for full regression suites where every non-deterministic field would otherwise need manual handling, Keploy removes the majority of that work.

All noise and secret configuration lives in keploy.yaml at the repository root. The `noise.global.body` array takes JSONPath expressions; `noise.global.header` takes header names. Example: `noise.global.body: - $.response.data.createdAt - $.response.data.token`. Rules can also be scoped to a single test case via a `noise` block inside the generated YAML test file. The docs at keploy.io/docs/concepts/noise cover every field and provide copy-paste templates for common application stacks.

Test with Keploy AI

Get the power of AI to your Testing Pipelines!

Join our GlobalCommunity

Connect with developers worldwide. Follow updates, ask questions, share feedback, and ship faster with other Keploy builders.

0M+installs

0K+GitHub

0K+devs

0M+mocks

0K+contrib...

#0OSS Trending