Build an API test fixture workflow that stays predictable

Separate generation from assertions, respect API limits and keep failures reproducible with a small fixture library.

Start with a behavior, not a large dataset

A test fixture earns its place by exercising a specific behavior. For a registration flow, that might mean an accepted country, a missing required field or a value at the length limit. Generating thousands of unrelated profiles can hide the scenario you actually need. Write down the input condition and expected response before choosing how many records to generate.

Keep generation outside the assertion

Fetch a synthetic record during setup, check that it contains the fields your application expects, and save a sanitized fixture for the test. The test should then exercise your own application. This separates a generator outage or exhausted allowance from a regression in the feature you are testing. A fresh random value on every assertion makes failures harder to reproduce.

Treat credentials as server-side configuration

Keep a Genory API key in your test runner’s secret configuration. Do not place it in a public repository, browser bundle or screenshot. Give the test job only the credentials it needs, and revoke a key when it is no longer used. Record response status and a correlation identifier in logs; avoid recording authorization headers or complete request bodies.

Budget requests deliberately

Start with one record and inspect the shape before requesting a paid batch. Developer usage is shared between the website and API. Free and Pro API access uses the separate lifetime trial. An HTTP 429 response requires checking whether the problem is a short-term request limit or an exhausted record allowance. Repeated retries cannot restore an exhausted allowance.

Make a failure reproducible

Store the exact synthetic input that produced a failure alongside the test case in your own controlled test environment. Keep real customer data out of that fixture. If a test failed after a timeout, do not assume that the server performed no work: automatic retries can repeat operations. Use bounded retry behavior only where repeating the operation is safe.

Worked example: a profile fixture for a registration service

Suppose your application accepts a profile and creates a local test user. You want to verify validation, persistence and the response shape. Calling a generator inside every assertion would add another service dependency and make failures harder to repeat. Instead, generate a small collection once, inspect it, and save approved synthetic records in your own repository or fixture store. The generator prepares inputs; your test decides what those inputs should demonstrate.

Keep only the required fields

Start with one valid record and state the fields your application actually needs. If registration only uses a display name and email, do not send banking details or an entire profile object. Replace contact destinations with addresses controlled by your test environment or reserved example addresses. Disable real mail delivery. A synthetic-looking address is not evidence that nobody owns it.

Separate fixture values from run identity

Create a separate local account identifier for each test run if your application requires uniqueness. Keep the source fixture stable and document the small transformation that makes a run independent. For example, attach a run-specific reference to your own test account record rather than regenerating every field. Avoid assertions against randomly changing values such as age or a freshly generated UUID unless their exact value is the subject of the test.

Save a fixture manifest

Store a short manifest beside the fixture: purpose, expected outcome, generator options, date captured and any edits made after generation. This is your own fixture record; Genory presets retain settings, not previous generated values. The manifest lets another developer distinguish an intentionally unusual input from an accidental typo. If you fix a bug, preserve the smallest record that still demonstrates it.

Assert your application contract

Make the automated test call your application and compare the response with the contract. Verify which fields are returned, which are normalized, and which must not be exposed. Read back the stored test record through your normal test access path. Finally, clean up that run’s records without deleting a shared environment’s unrelated data. A passing HTTP status alone is not proof that persistence or authorization is correct.

Generate variety when exploring. Preserve the exact input when proving a fix.

Treat API failures as failures, not empty fixtures

If fixture creation uses the Genory API, check the HTTP status before consuming the body as data. Authentication errors, exhausted allowance and rate limits need separate handling. A loop that retries every non-success response immediately can amplify a configuration problem. Keep the API key on a server or test runner, outside committed files and browser code. Current access and limits are documented in the API guide and pricing page.

Reserve fresh generation for a test that deliberately exercises that dependency. Keep your ordinary application tests able to run from saved fixtures when an external service is unavailable. This separation makes a failure easier to classify: did the generator return an unexpected response, or did your application mishandle a known record? Report the layer that failed instead of describing the whole pipeline as broken.

Use the Genory API documentation for current endpoints and authentication, and plan allowances for access limits. The separation of test layers here is a suggested workflow, not a guarantee about an external service.

Review the fixture library

Keep a small set of named scenarios rather than one enormous anonymous export. Remove fixtures that no longer test a supported behavior. When your schema changes, update the contract checks first so failures explain which field or type is no longer compatible. See the API documentation for current parameters, authentication and allowance details.

Continue with Genory tools, review documentation, or open your dashboard.