Free Argon2id Hash API Endpoint

Call the free Argon2id hash API endpoint

curl -X POST https://aisenseapi.com/services/v1/argon2id_hash \
  -H "Content-Type: application/json" \
  -d '{"password":"correct horse battery staple"}'

{"argon2id_hash":"$argon2id$v=19$m=65536,t=3,p=1$mWHnZ4Nxo3vEDMtb9cO7/A$PUXcfBGwUfBbXE1GgMiw4yPbY31fklKc0mRW99HBcsQ"}

Call it again with the same password and you get a different string: the salt is fresh every time, and that is the point of a password hash. Both strings verify. The field may also be called data, like the rest of the hash family, and a text/plain body works too. There is no file upload here, because a file is not a password.

Use test data. The string is kept by nobody here, but the password travels to a public service over TLS, and a real password belongs to the application that uses it. These routes exist to test, compare and generate fixtures.

Response fields

Field	Type	Description
argon2id_hash	string	The self-describing hash string: algorithm, cost, salt and hash. An empty password is refused with HTTP 400 and a `fix`; one over 1024 bytes with 413.

The parameters are fixed. m=65536 is 64 MiB of memory, t=3 three passes over it, p=1 one lane, and the hash is 32 bytes. Memory is what makes Argon2id expensive to attack with graphics cards and custom chips: an attacker has to pay for the memory as well as the time, per guess. On the API box one call takes about 100 ms of one core.

Verify a password

POST /password_verify takes password and the hash string. The algorithm is read from the string, so no field has to name it, and the answer carries the parameters that were read. A mismatch is a result, {"match":false}, not an error.

curl -X POST https://aisenseapi.com/services/v1/password_verify \
  -H "Content-Type: application/json" \
  -d '{"password":"correct horse battery staple","hash":"$argon2id$v=19$m=65536,t=3,p=1$mWHnZ4Nxo3vEDMtb9cO7/A$PUXcfBGwUfBbXE1GgMiw4yPbY31fklKc0mRW99HBcsQ"}'

{"match":true,"algorithm":"argon2id","params":{"m_kib":65536,"t":3,"p":1}}

Argon2id strings up to m=65536,t=3,p=1 are verified; a string that asks for more memory or more passes is refused with 400 and a fix, so nobody can make a verification cost more than a hash does. A hex digest sent here is refused with a pointer to /hash_verify, which is where digests are checked.

Cost, budget and the 503 you may see

One call is 100 to 230 ms of CPU on the server, 250 to 580 times a SHA-256. That is by design, and it is why these routes have a budget of their own beside the 5000 calls per day every address has: 200 password operations per IP address per day, hashing and verifying together, answered with 429 past that, and 20 000 per day for everyone, answered with 503. Both carry a Retry-After until midnight Oslo time.

The hashing runs in a process of its own, one computation at a time. While that process is busy with another caller the answer is 503 with Retry-After: 1 and "reason":"busy"; if it is down for any reason, 503 with Retry-After: 5 and "reason":"unavailable". Retry after the given seconds. Nothing else in the API is affected either way.

Why Argon2id, and when

Argon2id is the default choice for new password storage. It resists both side-channel attacks (the "i" half, data-independent memory access in the first pass) and GPU cracking (the "d" half, data-dependent access after that), which is why OWASP lists it before scrypt and bcrypt. If you are choosing a password hash today and have no legacy constraint, this is the one. Use scrypt where a system already stores scrypt, and bcrypt where one already stores bcrypt.

Common uses

Callers reach for the free Argon2id hash API endpoint in a handful of recurring situations.

Testing a login flow

Generate a handful of Argon2id strings for a test database without wiring the library into a script first, and check that your application verifies them.

Comparing libraries

Verify a string made by argon2-cffi, PHP's password_hash or Node's argon2 here. The PHC format is shared, so they all agree, and a disagreement points at an encoding bug on one side.

Reading a cost

/password_verify answers the parameters it read from the string, so a quick call tells you what profile an old hash was made with.

Teaching

Show what a salted, parameterised password hash looks like, and that two calls with the same password give two different strings that both verify.

Privacy and limits

The password travels in the POST body over TLS, never in a URL, and no part of it is logged or stored: the request log keeps the status and how long the answer took. It still reaches this service in the clear inside that connection, which is why the word above is test data.

The free Argon2id hash API endpoint shares the service-wide ceiling of 5000 requests per IP per day and has the password budget described above. No key, no account and no signup step stand in the way. Every route sits under the base URL https://aisenseapi.com/services/v1, and the whole catalogue is listed on Free public REST APIs.