MINARAGenerate TOTP secret
POST /v1/security/totp/generate — Mints a fresh TOTP secret for the user to add to an authenticator app, as an `otpauth://` URL (`qrCodeUrl`), a pre-rende
POST /v1/security/totp/generate
Mints a fresh TOTP secret for the user to add to an authenticator app, as an otpauth:// URL (qrCodeUrl), a pre-rendered PNG data URL (qrcode), and the base32 secret for manual entry. There are no backup codes. Step 2 of the Settings → Security enable wizard, and the call that replaces an existing binding: an account that still holds a secret can re-enable with its current authenticator instead.
| Method | POST |
| Path | /v1/security/totp/generate |
| Auth | Authorization: Bearer <token> required when GATEWAY_AUTH_TOKEN is set |
| Category | auth |
Response body
{ "secret": "JBSWY3DPEHPK3PXP", "qrCodeUrl": "otpauth://totp/Minara:[email protected]?secret=JBSWY3DPEHPK3PXP&issuer=Minara", "qrcode": "data:image/png;base64,..." }Notes
Failures answer with { error, status, message }, where error is the stable machine code. A rejected second factor maps to one of a stable set: invalid_totp, totp_required, invalid_email_code, email_code_required, verification_locked (too many wrong email codes; the message names the wait), totp_state_conflict (the account is already in the requested state), totp_not_provisioned (no secret generated yet), or rate_limited. Request-shape rejections answer 400 with totp_code_required, totp_and_email_required, or settings_payload_invalid depending on the endpoint. Anything the gateway cannot classify keeps that endpoint's own <action>_failed code with a generic message; the upstream wording stays in the server log.