Enterprise
Enterprise es el plan para organizaciones que superan Business: más miembros del equipo, sin límites de catálogo en proyectos y solicitudes, y límites que pueden ajustarse a tu contrato. Esta página explica qué incluye el plan, cómo Mockomat separa tu cuenta de las demás y cómo mantener coherente el modelado de dominio entre varios equipos.
Obtener Enterprise
Enterprise se acuerda con nuestro equipo comercial, no se compra en línea. Usa Hablar con ventas en la aplicación o el formulario de contacto; el precio es bajo consulta.
Qué incluye Enterprise
- Todo lo de Business: claves API, roles de equipo, exportación de código, analítica de endpoints.
- Sin límites de catálogo en proyectos, workspaces, solicitudes API mensuales, claves API por proyecto, tablas, atributos, relaciones, operaciones y notas del board.
- Hasta 26 miembros del equipo, 5 de ellos mantenedores.
- El paquete de código Enterprise: la exportación de código genera un backend NestJS y un frontend Angular (ver Exportación).
- Límites ajustados a tu contrato: nuestro equipo configura los límites de tu cuenta según lo acordado con ventas.
Para los límites de los demás planes, consulta Cuenta y planes.
Resumen del modelo de acceso a la cuenta y a los proyectos.
Cómo se separa tu cuenta
Enterprise usa la misma plataforma que cualquier otro plan. Estos límites se aplican a cada cuenta:
- Tu cuenta es el límite. Los proyectos, modelos, miembros, claves API y límites del plan pertenecen a tu cuenta. Cada solicitud se comprueba frente a ella, de modo que los miembros de otras cuentas no pueden abrir tus proyectos.
- Acceso a proyectos por miembro. Los mantenedores ven todos los proyectos de la cuenta. Los demás miembros ven los proyectos a los que se les dio acceso al invitarlos, con una anulación opcional por proyecto que puede restringir su rol, pero nunca elevarlo.
- Una clave API por consumidor. Cada proyecto de una cuenta solo responde en su mock API a solicitudes con una clave API de ese proyecto. Las claves pueden revocarse en cualquier momento.
- Datos mock compartidos y de solo lectura. La mock API sirve filas del pool de datos de Mockomat, que nuestro equipo importa y mantiene. Tus solicitudes solo lo leen, y es el mismo en todos los planes. No puedes subir tus propios datasets.
Límites de la cuenta, los proyectos y los datos.
Equipo y roles
| Rol | Qué añade |
|---|---|
| Solo lectura | Ve los proyectos, el modelo y la vista previa de datos; lee las notas del board |
| Reportero | Escribe y edita notas del board y sus comentarios |
| Editor | Construye el modelo, crea proyectos, gestiona las claves API, ejecuta la exportación de código |
| Mantenedor | Elimina proyectos, gestiona miembros y su acceso a proyectos, gestiona workspaces |
Cada rol incluye todo lo de los roles por encima de él. El propietario de la cuenta es mantenedor y gestiona la facturación. La lista completa de permisos y el flujo de invitación están en Team & Roles (en inglés).
Gestión de miembros del equipo y asignación de roles.
Sesiones y consumidores externos
- Sesiones de inicio de sesión: en Enterprise, el propietario de la cuenta puede mantener la sesión iniciada en varios dispositivos a la vez. Los miembros invitados no lo obtienen de la cuenta a la que se unen: solo pueden tener la sesión iniciada en un lugar a la vez, salvo que sean propietarios de una cuenta cuyo plan permita más, e iniciar sesión en otro lugar cierra su sesión anterior. Todos cierran sesión automáticamente tras un periodo sin actividad.
- Consumidores de la API: cada solicitud a la mock API lleva una clave API del proyecto. Usa una clave por consumidor o entorno (desarrollo, staging, CI) para poder revocar una sin afectar a las demás.
- Tokens de actor (opcionales): un consumidor puede solicitar un token de actor para que el uso simultáneo de una clave API pueda limitarse. Consulta la sección «Tokens de actor» de la página Integradores.
Modelo de gobernanza
Un enfoque práctico de gobernanza mantiene coherente el modelado de dominio a medida que se suman más equipos.
Propiedad de dominios
Asigna una responsabilidad clara para cada área de negocio:
- Responsable de dominio — responsable del nombrado de entidades, la definición de atributos y la estrategia de relaciones en su dominio.
- Revisores — miembros del equipo que revisan los cambios antes de que los consumidores dependan de ellos (el rol Reportero encaja).
- Consumidores — desarrolladores frontend e integradores que consultan la mock API sin modificar el modelo (el rol Solo lectura encaja).
Convenciones de nombrado compartidas
Define estándares para toda la organización sobre:
- Nombrado de entidades — PascalCase, sustantivos en singular, lenguaje de negocio (ej.
Customer, nocustomers_tbl) - Nombrado de atributos — camelCase, descriptivo, sin abreviaturas (ej.
totalAmount, notot_amt) - Nombrado de relaciones — dirección y cardinalidad claras
- Nombrado de operaciones — nombres en plural coherentes para operaciones de lista, en singular para operaciones de detalle
Mantén un proyecto de referencia que siga estas convenciones y cópialo con Forkar un proyecto como punto de partida de los nuevos proyectos.
Puntos de control de revisión
| Etapa | Foco de la revisión | Quién revisa |
|---|---|---|
| Cambio de modelo | Coherencia del nombrado, completitud de atributos, corrección de relaciones | Responsable de dominio |
| Cambio de exposición de la API | Operaciones, parámetros, tamaños de página | Responsable de dominio + integrador |
| Antes de exportar | Comportamiento del runtime, parámetros, ordenamiento, relaciones | Responsable de dominio + QA |
| Después de exportar | Código generado, límites de módulos, entradas | Líder del equipo de desarrollo |
Criterios de preparación
Define qué significa «listo» para cada entidad antes de que los consumidores dependan de ella:
- Cada atributo que necesitan los consumidores está vinculado a una columna de los datos importados
- Las relaciones se resuelven en la vista previa
- Los parámetros de operación y el ordenamiento devuelven las filas esperadas
- La paginación produce límites de página limpios
Controles de gobernanza en las etapas de modelado y runtime.
Seguridad
- Inicio de sesión: la aplicación usa un token firmado por sesión. Cerrar sesión, la inactividad y un cambio de contraseña terminan las sesiones en el servidor.
- Claves API: las claves son secretos. Úsalas desde código del lado del servidor, desde CI o a través de un proxy — nunca incluyas una clave en un bundle de frontend — y revoca una clave en cuanto deje de ser necesaria.
- Tráfico cifrado: la aplicación y la mock API se sirven por HTTPS.
- Sin datos de producción: las mock APIs sirven filas del pool de datos de Mockomat, así que tus entornos de prueba nunca necesitan datos reales de clientes.
Resumen de seguridad.
Buenas prácticas operativas
- Define criterios de preparación por entidad antes de asignarla a un equipo.
- Incluye comprobaciones de runtime en las revisiones — ejecuta la vista previa antes de que los consumidores dependan de un cambio.
- Exporta en hitos — guarda el código generado en control de versiones y anota de qué estado del modelo procede.
- Observa el uso — consulta la analítica de endpoints para ver qué operaciones llaman los consumidores antes de cambiarlas.
- Revisa con regularidad — mantén las definiciones de dominio alineadas con los requisitos de negocio cambiantes.
Validación del runtime enterprise y puntos de control operativos.