Provisioning de tenant desde superadmin

petid-adminpetid-apinotification-api
actualizado 2026-09-02

Objetivo

Dar de alta una clínica nueva (tenant + su admin) en un solo paso desde el panel de superadmin.

Cómo empieza

Superadmin en petid-admin, alta de tenant, con datos de la clínica + email/nombre del admin.

Pasos principales

1. ProvisionTenantUseCase.execute(): valida que el nombre de tenant y el email del admin no existan, genera slug, genera temp password (igual que en account-activation.md — nunca se expone).
2. tenants.createWithAdmin(tenant, user, profile) — transacción atómica en Postgres: tenant + user admin + profile, todo o nada.
3. Después de que la transacción confirma: notificationTenants.create(tenant.id, tenant.name) — llamada HTTP a notification-api para espejar el tenant allá. Esto ya no está dentro de la transacción.
4. Emite UserRegisteredEvent → dispara el flujo de account-activation.md (email de activación al admin).

Reglas de negocio

• El id del tenant en notification-api es el mismo UUID que en petid-api (created.tenant.id) — asumido en todo el resto del sistema como “mismo id en ambos lados”.

Interacciones

petid-admin → petid-api → Postgres (transacción) → notification-api (mirror, HTTP, con reintentos best-effort) → email vía account-activation.md.

Dónde seguir mirando

• petid-api/src/application/superadmin/provision-tenant.use-case.ts
• petid-api/src/infrastructure/notifications/notification-service-tenant-creator.ts (el cliente que llama a notification-api, reintenta y loguea si falla)

Casos especiales

• Si el mirror a notification-api falla (después de sus reintentos), el tenant queda creado en petid-api pero inexistente en notification-api — cualquier notificación futura para ese tenant fallará silenciosamente hasta crearlo ahí a mano. No hay compensación automática ni rollback del tenant en Postgres.
• Este gap ya se dio en la práctica: el tenant petid-system (creado por un seed script que llama prisma.tenant.upsert directo, no este use case) nunca pasó por este mirror y tuvo que crearse manualmente en notification-api — ver notification-template-routing.md.