Multi-Restaurante
Cómo modelar credenciales y clientes POS en apps multi-tenant y multi-local.
Las apps multi-restaurante no deben usar un set global de variables POS para producción.
Cada operación debe resolver qué tenant, restaurante y local están autorizados, y desde ahí cargar la conexión POS correcta.
No usar singleton global
Un cliente POS global puede mezclar credenciales entre restaurantes o locales. Construye el cliente con la conexión autorizada para la operación actual.
Modelo recomendado
Patrón runtime
const posConnection = await loadRestaurantPosConnection({
tenantId,
restaurantId,
localId
});
assertUserCanAccessLocal({ user, tenantId, restaurantId, localId });
const pos = createPosClient({
provider: posConnection.provider,
toteat: {
restaurantId: posConnection.externalRestaurantId,
localId: posConnection.externalLocalId,
userId: posConnection.externalUserId,
apiToken: posConnection.apiToken
}
});Rotación de credenciales
Las credenciales POS deben poder rotarse sin redeploy. Por eso deben vivir en storage seguro server-side, no en build-time env vars globales.
Storage seguro
Persiste credenciales cifradas o protegidas por secret manager/server storage.
Resolución por request
Lee la conexión POS después de validar tenant, restaurante y local.
Rotación sin deploy
Cambia token o local externo sin reconstruir la aplicación.
Variables locales permitidas
CARTAMATIC_POS_TOTEAT_* sigue siendo útil para:
- integration tests opt-in del SDK
- capturas locales controladas
- herramientas internas contra un local concreto
- despliegues intencionalmente single-connection
No es el modelo para dashboards multi-tenant.