Skip to content
SR Web Studio

A 33-Tenant Swoogo Event-Admin Platform Kept Alive by a Home-Grown Session-Automation Engine

How a 33-client Swoogo event-admin platform stays live 24/7 via a custom Puppeteer session-automation engine built to get around the platform's own API limits.

Browser mockup of an admin dashboard showing a multi-tenant client-accounts table, live stat tiles, and a session-automation activity log.
Illustration for this case study. Names and details are placeholders.

The problem

Six categories of integration needs, repeated across 33 different client accounts: CRM/ERP sync, SMS/WhatsApp messaging, mobile wallets, payment processing, interactive seating and booth tools, and social activity feeds. Each client wanted its own bespoke version. Compounding the problem, some Swoogo admin operations — including switching between client accounts — exist only in the browser UI. The public REST API doesn’t touch them. Staff couldn’t spend all day logging in and out of dozens of admin sessions by hand, so the agency needed a reliable way around that gap.

The approach / solution

  • Every client gets its own hand-built integration module in a NestJS 10 + TypeORM + PostgreSQL backend, and all 33 modules sit on the same shared set of “base” services — API keys, user/auth, Swoogo API access, page and help settings. That shared foundation is what lets a small team keep 33 tenants running.
  • The session-automation engine logs into one shared admin account with email/password plus TOTP two-factor authentication, then switches between all 33 client accounts inside a single persistent browser session, persisting each client’s session credentials to disk.
  • Browser automation fails eventually. So we built a reliability layer around it: randomized keepalive checks every few minutes (randomized specifically to dodge predictable automation patterns), an escalation path that re-switches the account after repeated keepalive failures, and — if that still doesn’t recover — a full browser restart with an alert sent out.
  • The frontend has shipped across two live generations, Svelte 4 and then Svelte 5, picking up a heatmap builder, booth-map tooling, an embedded payment flow, and public unauthenticated pages for heatmaps and booth maps along the way. Clients moved to the newer generation as their feature needs justified it. The ones still on the earlier generation kept working the whole time.
  • Role-based access control, a permissions/pages guard system, and TOTP two-factor auth cover the admin side, with a Socket.io gateway tracking connections as they happen.

Outcome / result

33 real client accounts run on this platform today, covering nearly every category an event-tech platform gets judged on: registration, bidirectional CRM/ERP sync, payments, SMS/WhatsApp/email communications, mobile wallets, and on-site tools like interactive seating and booth-visit heatmaps. All 33 stay reachable through one persistent admin browser session, with the automation catching and recovering from failures on its own. The frontend has grown too — 19 clients on its first generation, 25+ on the current one — without a disruptive full-platform rewrite.

Why it matters for enterprise event-tech

This is direct, verified evidence of platform engineering built around a major event-tech SaaS product’s own limits: something well past a standard API integration, closer to reliability infrastructure the platform itself doesn’t provide. That kind of multi-tenant, enterprise-integration depth is what separates a Swoogo specialist from a generalist agency. It lines up directly with an event-tech architect / MarOps engineering positioning.

Related service

Swoogo middleware and admin dashboard

Need help keeping a multi-tenant Swoogo platform reliable at this scale? Get in touch.