curl or a thin HTTP client is the right tool.
For the equivalent GraphQL operations, see the GraphQL API reference.
Required headers
Base URL:
https://your-gateway.example.com
Public endpoints
These don’t require authentication — they’re the way unauthenticated visitors enter the system.POST /auth/signup
Register a new user account.
Request:
If email verification is disabled, the user is auto-verified and can log in immediately.
POST /auth/login
Authenticate and receive an access/refresh token pair.
Request:
When JWE encryption is enabled, the
accessToken is a 5-part JWE string instead of a 3-part JWS. Both formats are accepted on inbound requests.
POST /auth/confirm-signup
Confirm an email with the 6-digit code.
Request:
Codes expire after 1 hour. Up to 5 attempts are allowed before the code is invalidated.
POST /auth/recover-password
Request a password recovery email. Always returns 200, regardless of whether the email exists, to prevent enumeration.
Request:
POST /auth/reset-password
Reset a password using the recovery code.
Request:
A successful reset clears any active account lockout.
POST /auth/refresh-token
Exchange a refresh token for a new access/refresh pair.
Request:
GET /auth/.well-known/jwks.json
Public JWKS endpoint for external services validating Archie-issued tokens. No authentication required.
Response (200):
kid mismatch.
Protected endpoints
RequireAuthorization: Bearer <accessToken>.
POST /auth/logout
Revoke the current access token and invalidate the associated refresh token.
Revoked tokens are tracked in a distributed blacklist until their natural expiry, so re-presenting the access token after logout fails with
401.
Error codes reference
Rate limits
429 responses include a Retry-After header indicating seconds to wait.
FAQ
Why does `/auth/recover-password` always return 200?
Why does `/auth/recover-password` always return 200?
To prevent email enumeration. If the response distinguished “exists” from “doesn’t exist”, an attacker could probe a list of emails and learn which are registered. Returning 200 either way removes that signal.
What's the safe way to validate tokens at the edge?
What's the safe way to validate tokens at the edge?
Fetch the JWKS from
/auth/.well-known/jwks.json and validate signatures locally. Cache the JWKS on your edge service; refresh on kid mismatch (which signals key rotation). Don’t call Archie on every request to validate.My token validates locally but Archie rejects it on the API — why?
My token validates locally but Archie rejects it on the API — why?
Most likely a revocation. Archie checks a distributed token blacklist on every request, so logged-out and force-logged-out tokens fail even if the signature is valid. The local-only validation can’t see the blacklist.
How do I handle 423 Account Locked?
How do I handle 423 Account Locked?
Surface a clear “account temporarily locked” message and either show the countdown from
lockedUntil or offer a password reset link — a successful reset clears the lockout.Can I rate-limit more aggressively for my own use case?
Can I rate-limit more aggressively for my own use case?
Put a Custom API in front of
/auth/login with a tighter rate-limit policy. The auth endpoint defaults are platform-wide; per-route Custom API config lets you go stricter.