Tu código, en tu servidor
Módulos en tu infraestructura y skills en el Hermes del tenant.
Un módulo propio sustituye a la pieza de Pimia
Corre en tu servidor y guarda sus datos en tu base. En la composición de tu vertical lo marcas como sustituto, y ningún plan tuyo recupera el nativo. Pimia no conoce su coste, así que no lleva «te cuesta». Y el cliente que sale de él, por ejemplo el que nace al convertir un lead, es de Pimia.
Probado con un CRM en producción
El CRM de la vertical de Zoomo, con sus leads, su embudo por etapas, su actividad comercial y la conversión a cliente, ya no vive dentro de Pimia. Es una aplicación propia del integrador, con su Laravel, su PostgreSQL y su despliegue, que habla con el ERP por la API pública y a través del SDK oficial, con el token del usuario que entra. Está desplegada sirviendo a una pyme y verificada desde la pantalla: las oportunidades que crea aparecen en el desplegable de presupuestos de Pimia como cualquier otra. Ciento dos tests y 348 aserciones en verde, donde se despliega.
GET /api/v1/crm/assignable-users 200
GET /api/v1/leads?limit=50 200
GET /api/v1/leads/4 200
GET /api/v1/leads/4/estimates 200
GET /api/v1/leads/4/activities 200Acceso a Pimia: sólo lo que tu módulo necesita
Dos capas que no se mezclan. Los permisos de las personas dentro de tu módulo los administras tú. Lo que tu módulo necesita de Pimia son scopes: se fijan al registrar tu cliente OAuth y el dueño de cada tenant los consiente. Un servicio que atiende una petición ya autenticada reenvía el token del usuario por petición, sin guardarlo ni refrescarlo. Y ningún código de partner corre dentro de Pimia.
Consultar clientes y responsables
Lectura: el censo de responsables sólo lo tiene Pimia.
Crear un cliente
El cliente nace en Pimia, con el scope que el dueño consintió.
Convertir un lead
El lead se cierra en tu backend; el cliente lo crea Pimia.
Skills para Hermes
Una skill nace de una tarea que tu cliente hace a mano; Pimia Capture, instalado en su puesto, te trae ese listado y te propone las candidatas. Una skill hace trabajo delegado en el Hermes del tenant. Cada una declara su tier, de T0 a T3 según las herramientas que toca (T2 y T3 exigen revisión de plataforma al publicar), y el nivel de verificabilidad, de 1 a 4, de cada subacción bloqueante; el nivel 4 exige intervención humana visible. El registro rechaza una skill sin esa declaración. La conexión de Hermes con las herramientas de tu módulo está en propuesta: aquí no se anuncia.
Describe el trabajo
Documentos, capturas o una transcripción del proceso, o la tarea que Pimia Capture señaló: sus entradas y el resultado esperado.
Especificación y grafo
Acciones, dependencias y decisiones, con aprobación del diseño antes de construir.
Construye con las herramientas del MCP
Los pasos de la skill y los recursos que necesita, sobre el MCP del tenant.
Backend sólo si hacen falta datos propios
Si la skill guarda datos suyos, un backend tuyo; si no, ninguno.
Veredicto y registro
Una skill rechazada se rediseña; una admitida declara su verificabilidad y se registra para el tenant.
Quién autoriza qué
Tres sitios donde se autoriza, no dos
Con un módulo propio, cada acción se autoriza donde vive el dato.
En tu backend
Ver, editar o borrar un lead de tu CRM: son tus datos, con tus permisos.
En Pimia
Crear o modificar un cliente: por su API, con el scope que el dueño consintió.
En los dos
Convertir un lead en cliente: tu módulo cierra el lead y Pimia crea el cliente.
Empieza hoy
Crea tu cuenta de desarrollador, conecta el SDK y levanta tu primera vertical con hasta cinco licencias de desarrollo sin cobro.