Call the free password API endpoint
curl https://aisenseapi.com/services/v1/password/20
{"password":"*1YSdSv.lb46<-s=Ez5l","password_length":20}That is the whole interface. One path, one optional number, one JSON object in reply.
The length segment can be left off. Drop it and the service falls back to its default of 12 characters.
curl https://aisenseapi.com/services/v1/password
{"password":"!wyU>EAn[zeo","password_length":12}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.
Read this before you use one for real
This password 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. Test fixtures need distinct passwords. Sandbox accounts need throwaway logins. A signup form under construction needs something that looks valid in the field. An onboarding flow needs an initial value a human is forced to replace on first sign in. None of those care that the string travelled.
Response fields
| Field | Type | Description |
|---|---|---|
| password | string | The generated password. Upper and lower case letters, digits and punctuation, mixed as in the samples above. |
| password_length | integer | The length actually used. Compare it against what you asked for rather than assuming the path segment was honoured. |
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.
The echoed length exists so you can check rather than hope. A single comparison against password_length catches a truncating proxy, a mangled path and a typo in your own string building, all before the value reaches storage.
When the length is out of range
A length outside the accepted window is rejected outright, never quietly clamped to the nearest legal value.
curl -i https://aisenseapi.com/services/v1/password/200
{"error":"The password length must be between 6 and 128 characters."}That body arrives with HTTP 400. Asking for 5 characters returns the same message and the same status, because the window is closed at both ends. A non-numeric segment such as /password/abc never matches the route at all and comes back as HTTP 404.
Refusing beats clamping. Silent clamping would hand you a shorter password than the one your code believes it stored, and the mismatch would only surface later, at a login screen, with no clue about where the length went.
Length beats cleverness
- Every character multiplies the work
Adding one character multiplies the space an attacker has to search. Moving from 12 to 20 buys far more resistance than any rearrangement of which symbols are allowed. When you have to choose, choose longer.
- The alphabet is already mixed
Both letter cases, digits and punctuation are always in play. There is nothing to configure and no reason to reach for a more exotic character set, which mostly buys arguments with input fields that reject it.
- Ask for what the target accepts
Some systems silently truncate long passwords. Request a length the target actually stores, then read
password_lengthback before writing the value anywhere. - The ceiling is generous
The upper bound of 128 is well past what any login form needs. It exists for callers filling fixed-width fields or stress testing their own validation.
Randomness a model did not invent
Ask a language model to make up a password and it will produce something drawn from its training distribution. 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 free password API endpoint returns something the model did not derive from a timestamp, a user name or its own token stream, which is exactly why it suits scaffolding work and still does not suit a real secret. The same reasoning applies to the UUID API endpoint when you need an identifier rather than a password, and to the random number API endpoint when a bounded integer is what the code is missing.
Common uses
Test fixtures
Seed demo accounts with distinct passwords instead of copying one literal across every test file.
Sandbox credentials
Throwaway logins for a staging environment that gets wiped on the next deploy anyway.
Form development
Fill a signup or reset form with a plausible value while the flow is still being built.
Forced-change placeholders
Issue an initial password that a human has to replace the first time they sign in.
Agent scaffolding
Hand an assistant a value it did not compose from anything already inside its context.
Validation checks
Ask for 6 and for 128 to confirm your own field rules behave at both ends of the range.
Privacy and limits
Generated passwords 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 password API endpoint when you want a value without installing anything, 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 password.