Roles y permisos
Controla qué puede hacer cada miembro con permisos granulares basados en roles
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 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 —
Ownery 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 para ver la lista completa de permisos otorgables y no otorgables.