Ruteo de notificaciones: tenant fijo + code por evento

petid-apinotification-api
actualizado 2026-09-02

Objetivo

Que cada evento de dominio dispare el email/push correcto, sin que la capa de aplicación conozca nada del sistema de templates de notification-api.

Cómo empieza

Cualquier evento de dominio con un handler on-*-event-send-{email,push}.handler.ts (ver application/handlers/).

Pasos principales

1. El handler llama a EmailSender/PushSender (puertos), nunca a notification-api directo.
2. EmailServiceSender/NotificationServicePushSender mapean el método a un code fijo + variables, y envían siempre bajo this.tenantId = env.NOTIFICATIONS_TENANT_ID — el tenant literal "petid-system", no el tenant real de quien disparó el evento.
3. El tenant real (la clínica) viaja aparte, como sourceTenantId — solo para logging/analytics en notification-api, nunca para resolver qué template o credenciales usar.

Reglas de negocio — codes actuales

Email (email-service-sender.ts): password-reset, welcome (verificación/activación), password-updated, account-deleted, 2fa-enabled, 2fa-disabled, new-login-email, visibility-enabled, visibility-disabled, contact-request.

Push (notification-service-push-sender.ts, code lo elige el handler): account-security-updated (2FA enable/disable y cambio de contraseña — mismo code, tres eventos distintos), contact-request-push, report-created, pet-tag-scanned, appointment-cancelled.

Interacciones

petid-api → notification-api (POST /notifications/{email,push}, header x-api-key) → notification-worker → FCM/APNs o el email-server.

Dónde seguir mirando

• petid-api/src/infrastructure/email/email-service-sender.ts, push/notification-service-push-sender.ts
• petid-api/src/infrastructure/notifications/notification-service-http-client.ts (retry compartido)
• petid-api/src/infrastructure/config/env.config.ts → NOTIFICATIONS_TENANT_ID

Casos especiales

• El tenant "petid-system" en notification-api fue creado por un seed script (prisma.tenant.upsert directo), no por ProvisionTenantUseCase — así que nunca pasó por el mirror normal. Si algún día hay que tocar su config de providers (FCM/email), el panel de petid-admin no funciona para este tenant específico (el proxy de superadmin valida contra el UUID de petid-api, que no coincide con el id literal "petid-system" en notification-api). Hay que llamar a notification-api directo con el API key compartido.
• Si cambiás el nombre de un code acá, tiene que existir un Template con ese code ya creado en notification-api para el tenant petid-system — si no, el envío falla silenciosamente (best-effort, solo loguea).