Platform Overview
What is GXP?
The Gramercy Experience Portal (GXP) is a modular platform for building event and experience applications. Rather than providing a single monolithic application, GXP gives developers a system for creating small, focused apps that serve as building blocks for attendee experiences.
Events built on GXP are assembled from these building blocks — registration pages, social feeds, agendas, leaderboards, chat widgets, analytics tiles, and more. Each piece is a plugin developed independently, versioned separately, and configured per-event by project admins.
Development Philosophy
GXP is built around a few core principles:
Small, Customizable Components
Every app on the platform is designed to do one thing well. A registration form, a speaker directory, a live polling page — each is its own plugin with a focused purpose. This keeps individual components simple and maintainable.
Focused Plugins, Not Feature Flags
Instead of one massive agenda plugin with dozens of feature flags and configuration fields, the platform would have multiple agenda plugins — each built for a specific style. A simple list agenda, an interactive multi-track agenda, and a timeline view are separate plugins with their own focused configurations. Admins browse the available options, choose the one that fits their event, and configure only what that plugin needs. They can swap plugins or use multiple ones without wading through irrelevant settings.
Direct Admin Configuration
Each plugin exposes a focused configuration form to project admins. Admins don't need to understand code — they configure behavior through purpose-built settings panels that plugin developers define as part of their plugin.
Independent Updates
Plugins are versioned independently. Updating a registration plugin doesn't affect the social feed or the agenda. Projects pin to specific versions and upgrade on their own schedule.
Developer Roles
Three types of developers interact with GXP:
| Role | What They Do | Tools |
|---|---|---|
| Plugin Developer | Builds apps (pages, widgets, themes, tiles) that extend the platform | GxP DevKit, Plugin APIs |
| Project Admin | Configures portals, selects plugins, customizes settings for events | Dashboard UI |
| API Integrator | Connects external systems via the REST API | REST API, Webhooks |
This documentation primarily targets plugin developers and API integrators.
High-Level Architecture
How It Fits Together
-
Teams own plugins — pages, widgets, themes, tiles, and plans. A team's developers build and publish plugin versions through the DevKit and dashboard.
-
Projects represent events. When setting up a project, admins select which plugins to use and configure them. Each plugin is installed as an instance pinned to a specific version.
-
Portals are the attendee-facing websites. A portal assembles plugin pages into a navigable site, applies a theme, injects widgets, and serves everything on a custom domain.
-
Dashboard tiles provide admin-side analytics — custom data visualizations that display project metrics.
-
Plugin plans are JSON-driven templates that can provision an entire project structure (portals, pages, widgets, forms, configuration) from a single template, enabling repeatable event setups.
Tech Stack
| Layer | Technology |
|---|---|
| Backend | Laravel 12 + Octane/RoadRunner, PHP 8.3 |
| Database | PostgreSQL 16 |
| Cache & Queues | Redis Enterprise |
| Frontend | Vue 3 + Inertia.js, Pinia, Vite |
| Auth | Passport (OAuth2) + Sanctum (tokens) + Fortify + Socialite (SAML2) |
| Real-time | Laravel Echo + WebSocket broadcasting |
| API | Laravel Orion (RESTful CRUD) + custom endpoints |
| Plugin Dev | GxP DevKit CLI + Vue 3 + Vite |
Next Steps
- Portal Architecture — How attendee-facing portals work
- Plugin System — Plugin types, versioning, and the security model
- GxP DevKit — Get started building your first plugin
- API Integration — Connect external systems via the REST API