# Roles y permisos (/es/security/roles-and-permissions) El control de acceso de Bitelio está construido sobre claves de permiso granulares `resource:action` — `campaigns:send`, `contacts:delete`, `team:manage`, y así sucesivamente. Todo miembro tiene un rol, y un rol no es más que un conjunto con nombre de estas claves. Cuando una solicitud llega a la API, el servidor resuelve el rol de quien llama a su conjunto de permisos y lo comprueba contra el endpoint que se está llamando. No hay ninguna barrera del lado del cliente que se pueda sortear: un miembro sin la clave correcta recibe un `403`, y punto. ## Roles predefinidos Cinco roles de sistema vienen con cada proyecto. No son editables ni eliminables — si necesitas algo intermedio, crea un [rol personalizado](#custom-roles) en su lugar. | Rol | Propósito | | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Owner** | Control total, incluyendo todo lo relativo al propio proyecto — el único rol al que se le puede confiar cambios a nivel de proyecto. | | **Admin** | El mismo acceso operativo que Owner, menos el control sobre el propio proyecto. | | **Editor** | Crea y envía contenido — campañas, contactos, segmentos, plantillas, flujos de trabajo — sin acceso a nivel de cuenta como facturación o gestión de equipo. | | **Analyst** | Acceso de solo lectura a campañas, contactos, segmentos, plantillas, flujos de trabajo y analítica. | | **Billing** | Gestiona la facturación y ve la analítica; nada más. | ## Roles personalizados Cuando los predefinidos no encajan, crea un rol personalizado con cualquier subconjunto de los permisos disponibles y asígnalo a un miembro. Los roles personalizados se comportan exactamente igual que los predefinidos en el momento de la solicitud — el servidor comprueba las mismas claves de permiso en ambos casos. ## Salvaguardas Unas pocas reglas evitan que los roles se usen para bloquear a todos o para ganar acceso adicional en silencio, más allá de lo previsto: * **Protección del último Owner** — el último Owner de un proyecto no se puede eliminar ni degradar. Siempre tiene que haber al menos uno. * **Sin escalada de privilegios** — solo puedes otorgar permisos que tú mismo tienes. Un Editor no puede crear un rol personalizado con `billing:manage`, ni siquiera para otra persona. * **Nombres reservados** — `Owner` y los demás nombres de rol de sistema no se pueden reutilizar para un rol personalizado, así un rol imitador nunca puede confundirse con el real. ## Gestión de roles Ve a **Ajustes → Equipo y roles** para ver la matriz de permisos y cambiar el rol de cualquier miembro desde un selector por miembro. Esta página en sí está protegida por el permiso `team:manage`, así que solo los miembros que ya lo tienen pueden cambiar el acceso de otros. ## Claves de API Las claves de API tienen un alcance independiente de los roles: cada clave secreta lleva su propio conjunto explícito de permisos, elegido al crearla, y nunca puede superar lo que tiene quien la crea. Consulta la [guía de claves de API](/es/guides/api-keys) para ver la lista completa de permisos otorgables y no otorgables. ## Qué sigue Añade un segundo paso de inicio de sesión encima del rol de un miembro. Volver al resumen de la superficie de control de acceso.