Perfil
Gestión del perfil del usuario autenticado: datos personales y tipos de usuario.
Listar tipos de usuario seleccionables
Retorna los tipos de usuario activos (`user_types.active = 1`), excluyendo siempre el tipo 1 (ADMINISTRADOR). Requiere autenticación. A diferencia de otros listados, `dataRecords` es directamente el arreglo (sin envoltorio `data`).
Obtener perfil del usuario autenticado
Retorna el usuario dueño del token. Un 200 solo indica que el token autentica: no se comprueba si el usuario o su empresa están activos (un usuario desactivado conserva sus tokens y recibe 200 con `active` = 0, aunque `POST /auth/login` lo rechazaría). Para saber si la cuenta puede operar, revise `active`. Respuesta idéntica a `GET /auth/user`. `dataRecords.data` es un arreglo con un único elemento.
Eliminar la cuenta del usuario autenticado
El titular elimina su propia cuenta confirmando su contraseña actual. Disponible para cualquier usuario que no sea administrador (`type_id` distinto de 1), también si su cuenta está inactiva. Efecto, en una sola transacción: (1) se revocan **todos** los tokens Bearer del usuario (incluido el de esta petición y los Personal Access Tokens): cualquier petición posterior con ellos responde 401; (2) se cierran sus registros de acceso activos; (3) se anonimizan sus datos personales: el correo pasa a `deleted+{id}+{marca de tiempo}@deleted.maticerts.invalid` (el correo original queda libre para registrar una empresa nueva; el NIT de la empresa conservada sigue registrado y no puede volver a registrarse sin intervención de soporte), `first_name` = `Usuario`, `last_name` = `eliminado`, sin avatar (el archivo se borra), sin contraseña utilizable y sin verificación; (4) `active` = 0 y la cuenta queda marcada como eliminada. **Se conservan** la empresa (incluido su correo de contacto, que puede seguir recibiendo avisos), su vínculo con el usuario, las solicitudes de certificado, los pedidos y los pagos, por las obligaciones legales de facturación electrónica y contabilidad. La acción no se puede deshacer desde la API. Límite: 5 peticiones por minuto por usuario (cuentan también las de contraseña incorrecta), además del límite general de la API.
Actualizar perfil de usuario
Actualiza el usuario `{id}`. Un usuario solo puede modificarse a sí mismo (otro `{id}` responde 403). Un usuario con la cuenta inactiva (`active` = 0) no puede modificar nada: responde 403 (`La cuenta está inactiva.`). El cuerpo lleva un único campo `records`: un **string** con un objeto JSON serializado (no un objeto JSON anidado). La fila actualizada es siempre la de `{id}`; `records.id` se ignora. Nunca se escriben `password`, `remember_token`, `email_verified_at` (enviado por el cliente), `current_password` ni las fechas de auditoría (la contraseña se cambia con POST /forgot-password y POST /reset-password). `type_id` y `active` no se pueden cambiar desde aquí: si se envían, se ignoran sin error. Avatar: enviar `imgdata` (data URL base64, p. ej. `data:image/png;base64,...`) y, opcionalmente, `imgname`; se guarda en `users/{id}/profile/{imgname}` (solo se usa el nombre del archivo, sin rutas; si `imgname` falta o es null se usa `avatar.png`) y se asigna a `avatar`. El contenido no se valida (ni formato, ni tamaño, ni tipo de imagen): se guarda tal cual tras decodificarlo. `imgdata` debe incluir el prefijo `data:...;base64,`: sin coma se descarta su primer carácter y el archivo queda corrupto, sin error. Si no hay nada después de la coma, el avatar no cambia y no se avisa. Si no se puede escribir el archivo, la respuesta es igualmente 200 y `avatar` queda apuntando a un archivo inexistente. El archivo se escribe antes de guardar los demás campos: si después el guardado falla (500), el archivo queda escrito pero `avatar` no cambia. `avatar` también se puede enviar directamente en `records` (texto, máx. 255) y se guarda tal cual, sin validar; si viene `imgdata` con contenido, la ruta calculada lo reemplaza. Longitudes: no se validan; un `first_name` o `last_name` de más de 120 caracteres (y un `avatar` de más de 255) se recorta sin error; un `email` nuevo de 255 caracteres o más no se recorta: responde 422 con el mensaje de correo que no puede recibir mensajes; y un `first_name` null se guarda como texto vacío. Correo: para no modificarlo, omita `email` en `records`. Si `records.email` es un texto distinto del guardado (se comparan sin espacios al inicio ni al final), debe poder recibir mensajes (sin tildes, eñes ni espacios intermedios antes de la @ y con dominio válido); si no, responde 422 y no se guarda nada. Si `records.email` no es texto ni null (número, booleano, arreglo u objeto) también responde 422 con el mismo mensaje, aunque no se esté cambiando el correo. Un `email` igual al actual no se valida, así que un usuario con un correo antiguo inválido puede seguir editando el resto de campos. Un `email` vacío, solo con espacios o null responde 422 (`El correo electrónico es obligatorio: no se puede dejar vacío.`) si el usuario ya tiene un correo: el correo de inicio de sesión no se puede borrar. Si el correo nuevo es otro (sin distinguir mayúsculas) y ya lo usa otro usuario, incluso uno eliminado, responde 422 (`Ya existe una cuenta con ese correo electrónico.`) y no se guarda nada. El correo se guarda sin espacios al inicio ni al final. **Cambio de correo:** cuando el correo cambia (sin distinguir mayúsculas; un cambio solo de mayúsculas no cuenta) se aplican, en este orden: (a) tope de 3 cambios guardados por hora por usuario (el de `{id}`, lo haga él o un administrador); el cuarto responde 429 (`Demasiados cambios de correo. Intenta de nuevo más tarde.`) con cabecera `Retry-After`; los intentos rechazados no cuentan. (b) Si el usuario cambia **su propio** correo (también un administrador), debe enviar su contraseña actual en `records.current_password`; si falta o no coincide responde 422 con `errors.current_password` (`La contraseña actual no es correcta.`). Tras 5 contraseñas erróneas en 15 minutos responde 429 (`Demasiados intentos con la contraseña actual. Intenta de nuevo más tarde.`) aunque la siguiente sea correcta. Un administrador que cambia el correo de otro usuario no la envía. `current_password` nunca se guarda y se ignora si el correo no cambia. (c) El correo nuevo no debe usarlo otro usuario (422). Después, el correo nuevo se guarda sin verificar (`email_verified_at` = null en la misma escritura), se envía el enlace de verificación al correo nuevo y un aviso de seguridad al correo anterior (con el correo nuevo enmascarado, p. ej. `nu*****@empresa.com`, y la indicación de contactar a soporte si no fue el titular). El aviso al correo anterior no se envía si el usuario no tenía correo guardado o si el correo anterior no puede recibir mensajes (por ejemplo, un correo antiguo con tildes o eñes); el enlace de verificación al correo nuevo se envía igual y la respuesta sigue siendo 200. Si alguno de los dos envíos falla solo se registra en el log y la respuesta sigue siendo 200 (el enlace se puede pedir de nuevo con POST /email/verification-notification). Un enlace de verificación enviado a un correo anterior ya no sirve. La sesión actual sigue activa, pero el siguiente POST /auth/login responde 400 (`El correo electrónico no ha sido verificado...`) hasta que se verifique el correo nuevo. La respuesta lo indica con `email_verification_required` = true. Aplica también cuando un administrador cambia el correo de otro usuario.