Generate identifiers for sample records, understand what UUID v4 means and avoid treating an identifier as a security control.
A prototype needs realistic identifiers before a backend is ready. UUIDs can be convenient for sample records because their recognizable format works across many systems. Generate them for the job you have, rather than assuming every unique-looking string is interchangeable.
What v4 tells you
UUID v4 is a UUID version based on random or pseudorandom data, with designated version and variant bits. The format and version rules are defined in RFC 9562.
For a prototype workshop list, each sample workshop can have its own ID. Keep those values stable in the fixture so references from bookings or examples continue to match.
Generate a small fixture deliberately
- Open the UUID v4 generator.
- Generate the identifiers you need.
- Assign each one to a named sample record.
- Reuse the same value wherever that record is referenced.
- Check that the consuming system expects UUID strings in that format.
Do not regenerate every identifier each time you edit a sample file. Otherwise, a screenshot, URL and API example can accidentally refer to different records.
Separate uniqueness from authorization
An identifier is not permission to access a record. Applications still need appropriate authorization checks. For passwords, secret tokens or production security requirements, use the system's purpose-built mechanisms rather than assuming a public generator meets those requirements.
Production systems should use a suitable UUID implementation and database constraints according to their design. A web utility is especially useful for documentation, mockups and small manual fixtures, where you can inspect the output before using it.
Try the generator for an invented record, then validate the surrounding payload with the JSON tool. Create a r37dy account when you need saved sharing links for your project.