Construir una app

Los desarrolladores pueden construir apps personalizadas para SweetHive - una pequeña vista de datos embebida en un contexto, o un producto completo en su propia URL. Registras la app una vez, recibes credenciales de cliente y construyes con el App SDK.

Dos tipos de app

Ambas se autentican de la misma manera: un token acotado de corta duración, limitado en el servidor por el alcance de la instalación y la visibilidad en vivo de quien la usa. Tu app nunca ve más de lo que puede ver la persona que la está usando, y el acceso se revoca en el instante en que lo pierde.

Registrar y construir

1. Abre Desarrollador → Apps desde el menú de usuario.
2. Elige Registrar app: ponle nombre, elige Embebida o Externa, configura la URL, el icono y la capacidad.
3. Guarda el client ID y el secreto (se muestran una sola vez).
4. Descarga la guía de desarrollo del SDK (.md) - el contrato completo: el handshake del iframe, la autenticación, la API de datos acotada, las pruebas y la publicación. Ponla en tu repositorio y construye con tu asistente de programación con IA. También disponible aquí: SWEETHIVE_APP_SDK.md.
5. Pon la app en Activa para que los administradores de hive puedan instalarla desde Contexto → Apps → Añadir app.

Cómo funciona el estándar

• Las apps embebidas se ejecutan en un iframe aislado y reciben un token acotado de corta duración mediante un handshake de postMessage - nunca una cookie, así que también funciona en las apps móviles. Tu app debe permitir que SweetHive la enmarque (una CSP frame-ancestors que incluya los orígenes de las apps móviles - la guía del SDK da la cabecera exacta).
• Las apps externas se abren en su propia URL con un lanzamiento firmado; en móvil se abren en el navegador nativo integrado en la app.
• Cada llamada de datos está limitada en el servidor por el alcance de la instalación cruzado con la visibilidad en vivo de quien la usa - la misma ley, la misma auditoría que cualquier actor de SweetHive.

Apps externas y hubs

Una app externa es un producto completo en su propia URL. SweetHive muestra una tarjeta de inicio; al hacer clic la app se abre con un inicio firmado y crea su propia sesión - en móvil, en el navegador nativo integrado.

Las apps externas en un origen autorizado también pueden iniciar la sesión de los usuarios directamente con su cuenta de SweetHive (SSO): con una sesión de SweetHive activa no se pide contraseña; de lo contrario el usuario inicia sesión en la página de acceso de SweetHive y vuelve directamente a la app. Solicita la autorización del origen al registrar la app.

Hubs multi-hive: una shell, muchas apps

Un producto que gestiona varios hives desde una sola interfaz sigue el estándar hub shell - una shell reutilizable modelada por un manifest:

• La shell proporciona, una sola vez para cada app: el acceso SSO, el selector de hive arriba a la derecha, la gestión de Equipo e Invitaciones, el tema claro/oscuro y la barra lateral plegable.
• El manifest (guardado con el registro de la app) declara la marca y las entradas del panel izquierdo. Cada entrada abre una vista integrada en la shell o - la parte clave - cualquier app embebida de SweetHive renderizada en un frame, sin cambios: una sola build sirve la interfaz del contexto y el hub.
• Cambiar de hive redefine el alcance de todo: la shell resuelve la instalación de la app en el hive seleccionado y recarga la vista activa, de modo que cada pantalla sigue al hive - incluidos los estados vacíos para hives donde la app no está instalada.

La guía del SDK contiene el contrato completo: el esquema del manifest, el handshake de las vistas y los errores a evitar.

Probar y publicar

Registra tu app con una URL de localhost, instálala en un contexto de prueba, y el handshake entrega un token acotado real contra tus datos. Cuando esté lista, ponla en Activa - y desactívala en cualquier momento; las instalaciones se detienen de inmediato.

Ajustes de la app

Una app instalada puede llevar ajustes por instalación - pequeña configuración que un admin del hive define (un recurso vinculado, una clave de integración, un modo). Se guardan con la instalación y se entregan en el payload de lanzamiento; la app los lee al iniciar y de nuevo cuando el admin los cambia, sin redespliegue. Úsalo para configuración. Los datos de dominio de la app (sus registros) van en tu propio almacén, indexados por instalación o contexto - SweetHive aporta identidad, alcance y personas/grupos; la app posee sus datos.

Roles y permisos

Un rol es un conjunto con nombre de las funcionalidades de tu app, asignado a grupos - nunca a personas individuales: los miembros lo heredan por su grupo. Los grupos y las personas vienen de SweetHive, listados para el contexto donde la app está instalada (la app los lee). Los roles son datos de tu app - créalos en tu almacén y asigna cada uno a los grupos correctos (con búsqueda sobre los grupos del contexto en hives grandes). Dos pasos en orden: crea el rol (nombre + funcionalidades), luego asígnalo a grupos.

Conecta las apps entre sí

Las apps no se llaman directamente entre sí: se conectan a través de la capa de conectores de SweetHive. Una app emite un evento (por ejemplo, "se capturó un lead") y un conector por hive lo enruta hacia la acción de otra app (por ejemplo, "registrar la atribución de marketing"). Activar o desactivar una integración es un ajuste, no código en ninguna de las dos apps, así las dos apps siguen siendo independientes.

• Registra una vez lo que tu app emite y lo que acepta (sus acciones).
• Configura un conector para un hive: app origen + evento hacia app destino + acción. Un administrador los gestiona desde la página Conectores; actívalos, desactívalos o elimínalos en cualquier momento.
• La entrega es best-effort: si la otra app no está disponible, el flujo de tu app no se ve afectado, y cada entrega queda registrada para que un administrador pueda ver qué ocurrió.

Un mapeo opcional de campos permite que cualquier evento alimente cualquier acción incluso cuando los nombres de los campos difieren, así las nuevas integraciones son pura configuración. La guía del SDK contiene el contrato de evento/acción y los endpoints exactos.