Usuarios Finales

Vincent Depassier · 30 de agosto de 2026

Un usuario final es una persona que se loguea en tu aplicación — un cliente, un jugador, el cliente de tu cliente. No son miembros de tu workspace de Praxsuite y nunca ven el portal.

El API Gateway les da su propio sistema de identidad: se registran, inician sesión, mantienen una sesión, y cada request que hacen lleva quiénes son. Eso es lo que le permite a la plataforma responder "mostrame mis pedidos" sin que tu backend tenga que hacerlo cumplir.

Se administran en API Gateway → End Users.

La pestaña End Users: cuentas, su origen, proveedor de auth, estado y verificación

Tres tipos de identidad, y por qué están separados

Praxsuite tiene tres, y confundirlos es el error más común al empezar.

	Quiénes son	Dónde se loguean	Qué gobierna su acceso a datos
Miembro del workspace	Alguien de tu equipo	el portal de Praxsuite	roles y permisos del workspace
Credencial / principal	Una aplicación	en ningún lado — sostiene una key	los scopes de tabla de la credencial
Usuario final	Un usuario de tu app	tu app, a través del gateway	los roles de gateway que tiene

Una API key responde "qué aplicación está llamando". Un usuario final responde "qué persona". Casi siempre necesitás los dos, y llegan en el mismo request: la key identifica la app, el JWT identifica a la persona.

La cadena de dos llaves

Esta es la forma que sigue toda app, y conviene tenerla clara antes de escribir código.

  tu API key (pk_live_ o sk_live_)
        │
        │  POST /{workspaceId}/auth/login
        ▼
  token de acceso del usuario (JWT)  +  refresh token
        │
        │  Authorization: Bearer <JWT>
        ▼
  consultas, endpoints, archivos, Event Bus — todo como esa persona

La key se usa para alcanzar los endpoints de auth. De ahí en adelante, el token del propio usuario es la credencial. Una app de navegador sostiene una key pk_live_ a la vista y un JWT por usuario en privado; esa combinación es lo que hace segura a un frontend público.

Los endpoints de auth son el único lugar donde tu API key toca las credenciales de un usuario. Nada más en el flujo la necesita.

De dónde sale un usuario final

Origen	Cómo aparece la cuenta
Autoservicio	Tu app llama `POST /auth/register` con una API key
Administrador	Alguien la crea en la pestaña End Users
Importación masiva	El botón Import, que valida el archivo antes de ejecutarlo
Proveedor externo	El primer login exitoso por un proveedor OIDC configurado crea la cuenta
Página alojada	Praxsuite sirve una pantalla de login lista en `https://portal.praxsuite.com/public/workspace/{workspaceId}/auth/login` — el enlace está arriba en la pestaña End Users

Ese último conviene saberlo antes de construir una pantalla de login: si solo necesitás que los usuarios se autentiquen, la página ya existe.

La cuenta en sí

Campo	Notas
`email`	El identificador. Único por workspace.
`authProvider`	`Local`, `Google`, `Microsoft`, `GitHub`, `Discord`, `Apple` o `CustomOIDC`
`providerSubject`	El subject del proveedor externo, cuando la cuenta no es local
`firstName` / `lastName` / `username` / `profileImageUrl`	Perfil
`settings`	Tus campos personalizados, indexados por las definiciones que configures
`isActive`	Desactivar revoca todas sus sesiones de inmediato
`emailVerified`	Si hizo clic en el enlace de confirmación
`lastLoginAt`	Vacío hasta su primer login exitoso
`roles`	Qué roles de gateway tiene — esto es lo que decide su acceso a datos

Los usuarios finales son por workspace. La misma persona logueándose en dos de tus workspaces son dos cuentas, con dos conjuntos de roles, sin relación entre sí.

Ciclo de vida

  registro ──▶ correo de confirmación ──▶ verificado
     │                                       │
     │                                       ▼
     └──────────────────────────────────▶ login ──▶ token de acceso (corto)
                                             │       + refresh token (largo)
                                             │
                                refresh ◀────┘
                                             │
                        logout / desactivar ──▶ sesiones revocadas

Tres puntos que definen cómo construís el cliente:

El token de acceso es corto y el refresh token es largo. Guardá el refresh token, usalo para pedir uno nuevo de acceso, y no hagas que el usuario vuelva a loguearse solo porque pasaron 30 minutos.
El refresh rota. Cada refresh devuelve un refresh token nuevo e invalida el anterior. Guardá solo el más reciente; reusar uno viejo falla.
La verificación no es un candado por defecto. Una cuenta puede loguearse antes de confirmar su correo — emailVerified te dice el estado, y es tu app la que decide qué puede hacer un usuario sin verificar.

Qué alcanza un usuario final

Una vez autenticado, ese JWT se acepta en todos lados donde el gateway acepta una identidad:

Consultas y mutaciones PraxQL — filtradas por los row filters de sus roles
Endpoints — tus automatizaciones expuestas por HTTP
Archivos — sujetos a los mismos permisos que las filas que los referencian
El Event Bus — el hub autentica usuarios finales y a nadie más

Lo que puede ver nunca lo decide la cuenta. Lo deciden enteramente los roles de gateway asignados — que es la página siguiente.

Desactivar y eliminar

Desactivar pone isActive en falso y revoca todas las sesiones de esa cuenta. La fila queda, el historial queda, y reactivar restaura el acceso. Es lo que querés en casi todos los casos.

Eliminar es permanente y se lleva los datos relacionados. No hay vuelta atrás.

Revocar una credencial no es instantáneo — el gateway cachea la búsqueda de credenciales hasta dos minutos, así que una API key revocada puede seguir siendo aceptada un rato. La revocación de sesiones de usuario final no pasa por ese caché y aplica de inmediato.

Endpoints de autenticación — registro, login, refresh, reset de contraseña y OIDC, con la credencial exacta que necesita cada uno.
Roles de gateway — cómo un rol decide qué filas ve un usuario final.