Call the free UUID API endpoint
curl https://aisenseapi.com/services/v1/uuid
{"uuid":"11ce9c91-0065-49a2-9864-ab5722a05969"}That is the whole interface. One path, one JSON object, one string inside it.
Ask again and the value changes. A second call made moments later returned 050752ad-e148-493e-850e-a65265a01343. Because there is no query string and no header to set, pasting the URL into a browser address bar counts as a complete test of the integration.
Response fields
| Field | Type | Description |
|---|---|---|
| uuid | string | A version 4 identifier. 36 characters, lowercase hex, written in five hyphen-separated groups of 8-4-4-12. |
Nothing is stored on our side. The same identifier is never handed out twice, and there is no way to ask for an earlier one back. Treat the response as the only copy you will ever see.
UUID or GUID
The value goes by two names. Windows, .NET and SQL Server tooling call it a GUID. Almost everyone else calls it a UUID. Both names describe the same 128 bits written in the same text layout, so nothing about the generation changes between them.
This page covers GET /uuid only. If the system receiving the value speaks in GUIDs and you would rather read it back under a matching key, the GUID API endpoint returns the same kind of value under a guid field instead.
Inside a version 4 identifier
A UUID is 128 bits. The canonical text form writes those bits as 32 lowercase hex digits, split 8-4-4-12 by hyphens, which is where the 36 character length comes from. Two of the groups are not fully random, and you can read that straight off the samples above.
- The version nibble
The third group opens with the version digit. In
11ce9c91-0065-49a2-9864-ab5722a05969that is the4in49a2. It says the value came from randomness rather than from a timestamp or a network card address. - The variant bits
The fourth group opens with a digit between 8 and b. The first sample starts that group with
9and the second with8. Those two bits mark the layout defined by RFC 4122 and its successor RFC 9562. - The remaining 122 bits
Version and variant consume six bits, which leaves 122 drawn at random. Collisions are not something ordinary applications need to design around at that width.
Identifiers without coordination
The point of a random identifier is that nobody has to be asked for it. There is no central counter to read, no sequence to lock and no round trip to a database to discover what the next number should be. The naming happens locally, in the moment, out of randomness alone.
That property is what makes the free UUID API endpoint useful in places a database sequence cannot reach. Any number of machines can mint identifiers in the same millisecond without stepping on each other. An offline client names a record before the network comes back. An agent names a thing before anything else has heard the thing exists.
Coordination is usually the expensive part of a distributed design. Removing it is worth paying for.
What the randomness costs
Independence is not free, and the bill arrives in three parts. Know the price before you make one of these values a primary key.
- Size. 36 characters as text, against a handful of digits for an integer. Multiply that across every row, every index entry, every foreign key and every log line and the difference stops being academic.
- No chronological order. A version 4 value carries no timestamp, so sorting by identifier tells you nothing about what came first. If creation order matters, you need a separate created-at column and an index to go with it.
- Scattered index writes. Consecutive inserts land at random points in the key space. A B-tree on a random primary key touches pages all over the file instead of appending neatly at the end, which costs cache locality and provokes page splits on write-heavy tables.
The common answer is to keep an internal sequential key for storage and expose the value from the free UUID API endpoint as the external, shareable identifier. Storage gets its tidy ordering. The outside world gets a name it can mint without permission.
Common uses
Idempotency keys
Mint one before sending a POST and attach it to the request. When a timeout forces a retry, the server recognizes the repeat and does not charge the card twice.
Correlation across services
Stamp an incoming request with a UUID and carry it through every downstream call and log line, so one search reassembles the whole path.
Offline-first clients
A mobile app or a field device creates records with no network, then syncs. Locally generated identifiers merge without renumbering anything.
Test fixtures
Give each test run unique record names and bucket keys, so parallel runs never collide on shared infrastructure.
Privacy and limits
These identifiers are generated on our server and travel back to you over the network. That is fine for record keys, correlation IDs and test data. It is not fine for cryptographic key material, session tokens or password salts. Generate those locally, inside the process that will use them.
Nothing about the request is retained beyond ordinary rate limiting, and the response carries no trace of who asked for it. The service-wide limit is 5000 requests per IP per 24 hours, shared across the whole catalogue of free public REST APIs.
That budget is generous for interactive work and for wiring up a prototype. It is not a substitute for a local library in a hot loop. Every mainstream language ships a UUID generator, and calling it costs no network at all. Reach for the free UUID API endpoint when you want a value without installing anything, not when you need a million of them a minute.