UUID Generator API: Why You Do Not Need One

The design intent

UUIDs were created so that independent systems could mint identifiers with no central authority and no coordination. Introducing a network call to obtain one reverses that property.

Every runtime has a built-in generator that takes microseconds:

crypto.randomUUID()   // JS      uuidgen           # shell
uuid.uuid4()          # Python   UUID.randomUUID() // Java
Guid.NewGuid()        // C#      Str::uuid()       // PHP/Laravel

What an API costs you

Latency measured in milliseconds instead of microseconds — a factor of a thousand for something on your critical path. An availability dependency: if the service is down, your application cannot create records.

Rate limits, a new failure mode to handle, and a third party that now knows how many entities you create and when. For a value your CPU can produce locally, none of this buys anything.

The legitimate cases

Coordinated sequential ids — Snowflake-style identifiers that need a shared node registry. That is not a UUID and the coordination is the point.

A constrained environment with no crypto primitives, such as some embedded or spreadsheet contexts, where a fetched value is genuinely simpler.

Test data generation, where a bulk endpoint returning a thousand ids is convenient — and even there, a local loop is faster.

If you build one internally

Make it a bulk endpoint returning many ids per call so clients can buffer, use a cryptographic random source, and set no-cache headers so a proxy never serves the same batch twice.

Then reconsider: a shared library that generates ids locally gives the same consistency with none of the network cost.