Cuando construyes un producto o una operación que sirve a VARIOS negocios sobre GoHighLevel (una plataforma de nicho, un revendedor con sistema propio, una agencia con software a medida), aparece el problema que define todo lo demás: el multi-tenant. Cada cliente vive en su subcuenta, tu sistema externo habla con todas, y una sola confusión de credenciales o un filtro olvidado significa que el dato del cliente A termina en la pantalla del cliente B. No hay categoría de bug más cara: no rompe el sistema, rompe la confianza.
Este artículo documenta la arquitectura multi-tenant que mantengo en producción sobre GoHighLevel: los tres niveles de identidad, dónde viven las credenciales de cada subcuenta (y por qué cifradas), y la defensa en dos capas contra la fuga entre clientes que es la regla número uno del diseño. No es teoría de seguridad: es el plano de un sistema real sirviendo negocios reales que no se conocen entre sí.
Respuesta rápida
- Los tres niveles: plataforma (tu sistema y su infraestructura), revendedor u operador (quien administra un grupo de clientes) y cliente final (cada negocio en su subcuenta). Cada nivel ve exactamente lo suyo y nada más.
- Identidad por subcuenta: cada cliente se registra con su PIT y su location ID propios, cifrados en la base; el sistema jamás usa una credencial global para operaciones de un cliente.
- Defensa en dos capas: Row Level Security en la base de datos Y filtro explícito por tenant en cada consulta del código. Ninguna capa confía en que la otra exista.
- La regla de oro: el identificador del tenant no viaja como parámetro confiable del cliente: se deriva del contexto autenticado, siempre, en cada petición.
| Nivel | Quién es | Qué ve | Con qué credencial opera |
|---|---|---|---|
| Plataforma | Tu sistema central | Todo, con auditoría | Credenciales de infraestructura, nunca expuestas |
| Revendedor / operador | Quien gestiona un grupo de clientes | Solo sus clientes | Sesión propia con alcance de grupo |
| Cliente final | Cada negocio | Solo su subcuenta | El PIT de SU subcuenta, cifrado |
Tres niveles, tres alcances, cero excepciones. Todo lo que sigue es la maquinaria que hace imposible saltarse la tabla.
¿Cómo se construye un sistema multi-tenant sobre GoHighLevel?
Con identidad de tres niveles (plataforma, operador y cliente final), credenciales cifradas por subcuenta (el PIT y el location ID de cada cliente) y defensa en dos capas: Row Level Security en la base más filtro explícito por tenant en cada consulta. El identificador del cliente se deriva siempre del contexto autenticado, nunca de un parámetro.
El registro del tenant: la ceremonia que define todo
Cada cliente entra al sistema con una ceremonia de alta: su subcuenta de GoHighLevel aporta el PIT con scopes mínimos y su location ID, y ambos se guardan cifrados (no codificados: cifrados, con clave que no vive en la misma base) en la fila del tenant. Desde ese momento, toda operación contra GoHighLevel para ese cliente usa SU llave: el sistema no tiene una credencial maestra que toque subcuentas ajenas en nombre de nadie. La consecuencia de diseño vale subrayarla: un incidente con la credencial de un tenant afecta a un tenant. La alternativa (una llave global de agencia para todo) convierte cualquier fuga en una fuga total, y cualquier auditoría en una pesadilla de atribución.
El location ID merece su párrafo: en la API de GoHighLevel identifica la subcuenta en cada llamada (con sus variantes de nombre según la familia de endpoints), y en tu sistema es LA columna que separa los datos de todos. Cada tabla con datos de clientes lleva su tenant y su location; cada webhook entrante se atribuye antes de procesarse; cada job en cola carga el contexto del tenant que lo originó. La atribución no es un metadato: es el eje del sistema.
La defensa en dos capas (porque una se olvida)
Capa 1: Row Level Security en la base
Postgres (Supabase en nuestra arquitectura de referencia) permite políticas de seguridad por fila: cada consulta, venga de donde venga, solo puede tocar las filas cuyo tenant coincide con el contexto autenticado de la sesión. Es la red de seguridad estructural: aunque alguien escriba mañana una consulta olvidando el filtro, la base se lo niega. Configurarla cuesta una tarde; su ausencia se paga con el punto de la confianza rota. Y tiene una virtud silenciosa: la política se define una vez por tabla y gobierna todas las vías de acceso presentes y futuras, incluido el dashboard de administración que todavía no has construido.
Capa 2: el filtro explícito en el código
Y sin embargo, cada consulta del código lleva ADEMÁS su filtro por tenant, explícito y visible. ¿Redundante con RLS? Exactamente, y a propósito: la defensa en profundidad existe porque las capas fallan de formas distintas. El RLS protege contra el descuido en el código; el filtro explícito protege cuando un proceso corre con privilegios elevados (los jobs de servicio que legítimamente cruzan tenants para mantenimiento), documenta la intención en el lugar donde se lee, y hace que los tests puedan verificar el aislamiento sin depender de la configuración de la base. La regla de revisión de código es binaria: consulta sin filtro de tenant visible, consulta rechazada, tenga RLS detrás o no.
La regla de oro: el tenant nunca es un parámetro
El error de diseño que más fugas produce en sistemas multi-tenant no es criptográfico sino conceptual: aceptar el identificador del cliente como parámetro de la petición («dame los datos del location X») y confiar en él. El identificador correcto se deriva SIEMPRE del contexto autenticado (la sesión, el token, el webhook verificado) del lado del servidor. Si la petición dice «soy el cliente A» pero la sesión dice B, manda la sesión, y el intento queda registrado. Esta regla convierte la clase entera de ataques y errores de «cambiar el ID en la petición» en imposibles estructurales.
Cuándo NO necesitas nada de esto
Si tu sistema sirve a UN negocio (aunque tenga varias subcuentas propias), el multi-tenant es armadura sin guerra: un buen manejo de credenciales por subcuenta te basta, y el aislamiento entre clientes que no existen no protege a nadie. La arquitectura de este artículo se justifica cuando hay clientes AJENOS entre sí compartiendo tu infraestructura, que es cuando la fuga deja de ser un bug y se vuelve un evento reputacional. Y si tu modelo es revender GoHighLevel sin sistema propio encima, el SaaS Mode nativo de la plataforma ya resuelve el aislamiento: esta arquitectura es para cuando construyes software TUYO sobre las subcuentas.
Errores comunes
- La credencial maestra para todo: una llave de agencia operando datos de todos los clientes. Cómoda el día uno, catastrófica el día del incidente, inauditable siempre.
- Tokens en texto plano: los PIT de los clientes son las llaves de SUS negocios; guardarlos sin cifrar convierte cualquier acceso a tu base en acceso a todas las subcuentas.
- Confiar en una sola capa: «ya tenemos RLS» hasta el job privilegiado que lo esquiva, o «el código siempre filtra» hasta el desarrollador nuevo. Dos capas, siempre.
- El tenant como parámetro: aceptar el location ID que llega en la petición sin derivarlo del contexto autenticado es dejar la puerta con el cambio de un número.
- Webhooks sin atribución verificada: el webhook entrante que se procesa sin confirmar a qué tenant pertenece (por su secreto y su origen) es la vía de entrada de datos cruzados.
- Logs que mezclan clientes: la observabilidad también es multi-tenant: los registros sin tenant no permiten auditar quién vio qué, que es la pregunta exacta del peor día.
Un caso real de esta arquitectura, con el cliente anonimizado: construir un SaaS multi-tenant sobre GoHighLevel, con las decisiones que se tomaron antes de configurar nada y lo que la producción obligó a cambiar después.
Preguntas frecuentes
Depende de qué automatizas: operar las subcuentas existentes de tus clientes funciona con el PIT de cada una (plan con API completa). Crear subcuentas y cargar snapshots programáticamente en el onboarding sí requiere las capacidades de agencia del plan Pro.
Es la mejor primera capa y no debería ser la única: los procesos con privilegios de servicio la esquivan legítimamente, y ahí solo el filtro explícito del código te protege. La combinación de ambas es el estándar por una razón: fallan de formas distintas.
Como ceremonia con checklist: generación del PIT con scopes mínimos desde su subcuenta, registro cifrado, verificación de conectividad con una llamada de lectura inocua, y alta de sus webhooks con secreto propio. Automatizable de punta a punta, pero nunca implícito.
La baja es tan importante como el alta: revocar su PIT desde la subcuenta, purgar o archivar sus datos según lo pactado, desactivar sus webhooks y dejar el registro de la baja. El tenant fantasma con credenciales vivas es deuda de seguridad pura.
Completo: los tres niveles, el cifrado de credenciales por tenant, la doble capa y la regla del contexto autenticado son arquitectura multi-tenant general. GoHighLevel solo aporta las particularidades (PIT, location ID y sus quirks); el esqueleto viaja a cualquier plataforma.
Arquitectura verificada en un sistema propio en producción sirviendo múltiples negocios sobre GoHighLevel con aislamiento completo, a julio de 2026. Si estás construyendo un producto sobre subcuentas de clientes, este es exactamente el tipo de sistema que diseño.
La idea que no se negocia
En multi-tenant, el aislamiento no es una funcionalidad: es la premisa que hace posible todo lo demás. Los clientes te confían sus datos bajo un supuesto que nadie firma pero todos asumen: que tu sistema es, para efectos prácticos, un sistema distinto para cada uno. Las tres piezas de esta arquitectura (identidad por niveles, credenciales propias cifradas, doble capa con contexto autenticado) son la forma de que ese supuesto sea verdad estructural y no buena conducta. Porque la buena conducta tiene días malos, y la estructura no.
