Call the free passphrase API endpoint
curl https://aisenseapi.com/services/v1/passphrase/4
{"passphrase":"hudil-rosi4-Zerzo-Coze#","groups":4,"length":23,"entropy_bits":91.4}That is the whole interface. One path, one optional number, one JSON object in reply.
The number segment can be left off. Drop it and the service falls back to its default of 4 groups.
curl https://aisenseapi.com/services/v1/passphrase
{"passphrase":"vodan-Fugi-tozer7-Bami!","groups":4,"length":23,"entropy_bits":90.7}No body travels with the request. No header needs setting. Pasting either URL into a browser address bar is a complete test of the integration.
The number counts groups, not characters
/passphrase/4 asks for four groups and returns roughly twenty-three characters. /password/4 would ask for four characters. The same number means a completely different thing on the two routes, and that difference is the reason this is a separate endpoint rather than a style flag on /password.
A group is one syllable pair such as hudil or Coze. About half of them close on a second consonant, which is why the total length shifts from call to call even when the group count does not. The response carries both numbers, groups and length, so neither has to be inferred from the string.
Nothing is padded or trimmed to hit a round length. If your field has a hard character limit, read length from the response and check it there rather than guessing a group count that will always fit.
Response fields
| Field | Type | Description |
|---|---|---|
| passphrase | string | The generated passphrase. Hyphen separated groups, one digit and one symbol always present. |
| groups | integer | The number of groups actually used. Compare it against what you asked for rather than assuming the path segment was honoured. |
| length | integer | Character count of the finished string, hyphens included. Varies between calls at a fixed group count. |
| entropy_bits | number | Bits accumulated across the random draws that produced this specific passphrase. |
The digit and the symbol are not decoration. Complexity rules that demand both are close to universal, and a passphrase that trips them at the point of entry is worse than useless, so one of each is always in the string.
The consonant set omits q, x and y. None of the three has a single unambiguous sound when read aloud, and a value that two people spell differently over a phone has lost the only property this endpoint exists to provide.
Nothing is stored. Each call produces a new value, the same value is never handed out twice, and there is no way to ask for an earlier one back. The response is the only copy you will ever see.
What entropy_bits actually counts
The number is accumulated at each random draw that went into the passphrase, not estimated afterwards from the finished string. Counting characters would overstate it: Zerzo looks like five characters from a large alphabet and is really four uniform choices from small ones.
Because it is measured per result rather than per setting, two calls at the same group count come back some bits apart, depending on how many syllables drew a closing consonant. The spread is wider than it looks: at the default of 4 groups the observed range over 4000 generations was 74.6 to 107.9 bits around a mean of 91.4.
| Groups | Mean | Comparable to |
|---|---|---|
| 2 | 48.9 bits | fine against online guessing, weak against an offline crack |
| 4 (default) | 91.4 bits | a 14 character fully random password |
| 6 | 132.7 bits | past the point where the passphrase is the weak link |
| 12 | 255.6 bits | key material, not something a person retypes |
Those figures are measured over 4000 generations each, and every one lands within 0.2 bits of what the construction predicts analytically.
Two groups is offered because short passphrases have honest uses, throwaway test fixtures among them. It is not a sensible choice for a credential that will face a stolen password database, and the number is on every response so that choice is never made silently.
When the group count is out of range
A count outside the accepted window is rejected outright, never quietly clamped to the nearest legal value.
curl -i https://aisenseapi.com/services/v1/passphrase/20
{"error":"The number of groups must be between 2 and 12."}That body arrives with HTTP 400. Asking for 1 group returns the same message and the same status, because the window is closed at both ends. A non-numeric segment such as /passphrase/abc never matches the route at all and comes back as HTTP 404.
Refusing beats clamping. A silently shortened passphrase would carry far less entropy than the one your code believes it issued, and nothing in the string would give that away.
Read this before you use one for real
This passphrase is generated on our server and travels back to you across the network. It has already left the machine that will use it. Never let one protect anything real: not a master password, not a production credential, not an account that holds value. Generate those locally, inside a password manager that never puts the secret on the wire.
That boundary is not a formality. A secret stops being a secret the moment it crosses a wire you do not own, and no amount of transport encryption changes the fact that a second party produced it. Treat every value from this route as public from birth.
What remains is still a large and honest slice of daily work. A passphrase read out to a colleague, typed on a television remote, printed on an onboarding sheet or spoken into a support call is exactly the case where a random string fails and this one does not.
Randomness a model did not invent
Ask a language model to make up a passphrase and it will produce something drawn from its training distribution, usually real dictionary words in a familiar order. Worse, it may produce something close to it again the next time a similar prompt arrives. Neither property is obvious from looking at the string.
Fetching the value over HTTP breaks that link. The syllables here are drawn at random rather than recalled, which is why the result stays readable without being guessable from the same corpus everyone else trained on. When character soup suits the target better, the password API endpoint covers it, and the UUID API endpoint covers the case where an identifier rather than a credential is what the code is missing.
Common uses
Dictated credentials
Anything that has to survive being read over a phone line without a spelling alphabet.
Device setup
Wi-Fi keys and console logins typed on a remote control or an on-screen keyboard.
Onboarding sheets
An initial value printed on paper that a human has to type once and then replace.
Test fixtures
Seed accounts with distinct passphrases that stay legible in a failing test log.
Agent scaffolding
Hand an assistant a value it did not compose from anything already inside its context.
Validation checks
Ask for 2 and for 12 to confirm your own field rules behave at both ends of the range.
Privacy and limits
Generated passphrases are never written down on our side. Each request produces a new value, and nothing links it back to the caller beyond the rate limit counter.
The base URL is https://aisenseapi.com/services/v1. There is no API key and no account to open. 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 comfortable for interactive work and for wiring up a prototype. It is not a substitute for a local library in a loop. Reach for the free passphrase API endpoint when the value has to be readable by a person, and browse the other random generator APIs when the thing you are short of is an identifier, a number or a color rather than a credential.