How to Create Safe Synthetic API Test Data

Problem and expected outcome

Production copies make tests look realistic at the cost of privacy, access control, retention, and incident-response risk. Random strings alone are not enough when the system depends on relationships, locales, boundaries, and validation rules.

Build synthetic datasets from the contract and test cases, not by anonymizing a convenient production export.

Debugging sequence

• List required shapes, relationships, equivalence classes, and boundary values.
• Use reserved example domains, documentation IP ranges, obvious synthetic names, and generated identifiers.
• Create deterministic seeds where repeatability matters and cryptographic randomness only where unpredictability is the behavior under test.
• Tag records with a test-run identifier and cleanup policy.
• Review fixtures for accidental secrets before committing.

Synthetic example

{
  "id": "018cc251-f400-7abc-8def-1234567890ab",
  "email": "qa-order-42@example.test",
  "name": "Synthetic Customer 42",
  "token": "NOT_A_REAL_TOKEN"
}

QA checks and boundaries

• Values are clearly fictional when screenshots escape the test environment.
• Uniqueness and referential relationships remain valid.
• Unicode, length, null, and boundary cases are represented.
• Cleanup is safe and scoped by a test marker.

Security and false assumptions

• Hashed or Base64-encoded production data may still be identifiable.
• Do not use real email domains that could deliver messages.
• Synthetic credentials must not grant access anywhere.

Preserve behavior, not identity

A useful synthetic dataset preserves relationships and troublesome shapes: two orders share one customer, an item reaches a length boundary, a name uses combining characters, and timestamps span a transition. None of those cases requires a real person's values.

Make fictional data obvious. Reserved example domains, documentation IP ranges, labels such as SYNTHETIC, and non-routable credentials reduce the chance that an escaped screenshot is mistaken for a real account or sends mail to an uninvolved person.

Determinism versus secure randomness

Use a recorded seed or fixed fixtures when a test must reproduce the same graph. Use crypto randomness when testing unpredictability, uniqueness, password generation, or collision behavior. Do not use Math.random for security-related values simply because a test environment is temporary.

Record only the seed for nonsensitive deterministic generation, not a copy of private production input. Cleanup should select the run namespace and verify the target environment before deleting anything.

Fixture review questions

• Could any email, phone, address, account, or token belong to a real person or service?
• Are boundary lengths, Unicode, nullability, and relationships represented?
• Can parallel runs create unique records without sharing mutable state?
• Can cleanup identify only records created by the run?
• Would the fixture still be safe if copied into a public bug report?

References

• IANA Example Domains
• RFC 5737: IPv4 Documentation Blocks
• RFC 3849: IPv6 Documentation Prefix

FAQ

Related guides