The problem
Universities don’t treat data isolation the way a typical event client does. Compliance and data-separation expectations run higher, and a shared-schema, shared-database multi-tenant model doesn’t satisfy those expectations as cleanly as giving each client its own physically separate database. The agency needed a second multi-tenant platform for exactly that group — five clients, higher-education-leaning. Stronger isolation mattered more here than the convenience of one shared database.
The approach / solution
- Each of the five client accounts got its own fully separate PostgreSQL database in a NestJS + TypeORM backend, with one routing middleware layer resolving the right connection per incoming request. That’s the textbook “isolate by database” multi-tenant pattern, chosen deliberately as the opposite of the shared-database approach on the larger sibling platform.
- One client’s Swoogo registration data connects to both a student information system and an enterprise CRM, plus a student task-management tool, with per-student custom field mapping and PDF file management built on top.
- For another client, most of our Swoogo integrations pull registration data in — this one also pushes it out, via an outbound webhook pipeline that feeds a third-party attendee-engagement platform (Jublia) as registrations happen.
- Per-event Apple/Google Wallet customization for another client, with colors and timing configurable per event, not fixed to one design across the board.
- Another client’s Swoogo data connects to a CRM platform, with registration field mapping alongside it.
- A fifth client came onboard using the same tenant-provisioning pattern — API-key storage and scaffolding — even before its full integration logic was built out. That shows the onboarding process repeats cleanly across clients, without needing to be reinvented each time.
- The integration runs purely against Swoogo’s public REST API. No browser-automation layer here — a more conventional build than the Puppeteer-based session-automation engine on the sibling platform.
Outcome / result
The agency now runs two live multi-tenant Swoogo platforms on two different isolation models: shared-database for the larger 33-client system, database-per-tenant for this five-client system. Each pattern was matched to what its own situation actually needed. This one has no browser-automation layer of its own, making it the more conventional of the two builds — a straightforward, fully API-driven system that extends the same Swoogo-integration skillset into higher-education and institutional territory, past the events-and-associations space where most of our other work sits.
Why it matters for enterprise event-tech
Multi-tenancy isn’t one trick, and here’s the proof: a shared-database system and a database-per-tenant system, built for the same agency, side by side. That combination tells a stronger architecture story than either platform would alone. The higher-education integrations on this one — student information systems, CRM, task management — also stretch the pitch past event-tech alone, into adjacent institutional and SIS integration work.
