Skip to content

Sponsor Services — Capability & AI-Readiness Brief

A capability overview of the Foxtrot November Sponsor Services offering, written for sales, solutions, and leadership use (RFP responses and AI-forward event pitches). Grounded in the shipped code across sponsor-services (portal), purchases-api, sponsor-users-api, sponsor-pages-api, sponsor-reports-api, scanbadgeapp, summit-api, and the Show Admin sponsor module. Client/event names intentionally omitted — swap in the audience's own examples when pitching.

Companion: Digital Signage — Capability & AI-Readiness Brief · Repository Reference.

In one line

A complete sponsor operations platform — self-service commerce, deliverables, and lead retrieval for sponsors; full program control for organizers — built as composable, API-first microservices on the same identity, event-stream, and Kubernetes backbone as the rest of the platform, with an OAuth2 REST surface that FN's own scanning devices and third-party integrations speak alike.

1. What it is

Everything a sponsor does around an event, in one portal, under one login:

  • One identity everywhere ("FNid"). The same OpenStackID login signs the sponsor into the portal, registers them for the event, and signs them into the lead-retrieval device or app. Passwordless email-OTP login is supported alongside standard OIDC.
  • Self-service commerce — tier-scoped order forms, a cart spanning multiple forms, time-windowed pricing (early-bird → standard → onsite), card + ACH checkout (Stripe) or invoice/wire-transfer checkout, order history with branded invoice PDFs.
  • Deliverables & content — per-tier document downloads (artwork templates, manuals), deadline tracking on the dashboard, and deliverable uploads with per-item deadlines, size limits, and status states (pending → deadline alert → missed → complete). The page system is composable — info modules, collection modules (text/graphics inputs), and download modules — so shows stand up new sponsor workflows as configuration: e.g. the Booth Staff workflow ships today as a page configured to collect staff names, with no portal code change.
  • Lead retrieval — badge scanning on the expo floor with custom qualification questions, notes, post-scan editing, and one-click CSV export of the company's leads.
  • Show-access flow — a sponsor user requests access to a show; organizers approve from the admin console; accounts and IDP group membership are provisioned automatically.

2. Provenance: ported and re-architected

Sponsor Services began life as a legacy Laravel application. It was ported into the platform as three bounded-context microservices — commerce (purchases-api), access control (sponsor-users-api), and content/deliverables (sponsor-pages-api) — preserving the proven functional core (forms → cart → purchase ledger, three-tier rate pricing, card + wire-transfer payment, show-level and sponsor-custom forms) while adding what a monolith couldn't:

  • Payment hardening — PaymentIntent idempotency, webhook-verified Stripe callbacks, a separate refund state machine with cumulative caps, and background reconcilers (orphan-payment cleanup, queued-refund drain, webhook-miss reprocessing) so money state is self-healing.
  • A global catalog — order-form templates cloneable across shows from a shared inventory service, instead of hand-rebuilding forms per event.
  • Centralized sponsor authz — access rights as data (user × sponsor × show × role), an approval workflow, and automatic IDP synchronization.
  • An event backbone — services stay consistent via RabbitMQ domain events (summit/sponsor metadata feeds, add_ons_purchased, permission changes) rather than shared databases.

3. Lead generation — devices, offline, and an open API

  • Three scan modes, all shipped: phone camera (ML Kit), dedicated Zebra enterprise scanners (DataWedge integration — the hardware-scanner path), and Bluetooth barcode guns.
  • Offline-first capture. Scans queue locally on the device (SQLite) and auto-sync — periodic upload plus an immediate flush when connectivity returns. Expo-floor Wi-Fi cannot lose a lead.
  • Qualification built in. Per-sponsor custom questions (with mandatory enforcement at scan time), free-text notes, and post-scan editing in the portal. Admins configure per-sponsor lead report columns; sponsors export their leads as CSV in one click.
  • Real-time availability. Leads appear in the portal as they're captured.
  • Third-party scanners are a first-class integration. The badge-scan surface is ordinary OAuth2-protected REST on the platform API (POST/GET/PUT /summits/{id}/badge-scans, /me, /csv) — and the server decrypts the badge QR itself, so an integrator never touches encryption keys. A dedicated authz group exists for external integrations (sponsors-external-users, e.g. a sponsor's own CRM or scanning vendor). Tenancy is enforced server-side: a sponsor's users see only their company's scans.

4. The organizer side — full program control in Show Admin

Operators run the entire sponsor program from the admin console: sponsorships/tiers and add-ons, sponsor users and access-request approval, order forms per show (built from the global template library, item inventory management), purchases administration (order grid with reconciliation view, status changes, refunds, invoice/payment views, show-level rollups), lead-scan administration (including manual scan entry and export), deliverables/pages management, and two operational reports — Sponsor Assets (deliverable completion by sponsor/tier/page) and Purchase Details (per-line-item logistics grain with paid/pending tiles) — backed by a dedicated reporting read model (star schema, minute-level sync, nightly reconcile).

5. AI-ready by architecture (the headline)

The same properties that make the stack composable make it the natural surface for AI tooling:

  1. Every service is API-first with a machine-readable contract. All sponsor microservices ship OpenAPI schemas (with Swagger UIs) — an AI agent can read the contract and operate the platform: build carts, query orders, pull leads, file deliverables.
  2. Order forms are pure data, rendered by a generic engine. Forms, items, rate windows, and custom meta-fields are server-defined records — the portal renders whatever the data says. That means AI can author or adapt a show's entire commerce catalog (from a prospectus PDF, a prior show, or a prompt) by writing data, not code — and clone it across shows via the template library.
  3. A real event stream. Domain events over RabbitMQ (add_ons_purchased, payment profile and permission changes, the full show/sponsor metadata feed) give automation a push-based integration surface, already proven by the services consuming each other.
  4. Per-show behavior is configuration, not code — pricing windows, wire-transfer instructions, access-request policy, page/deliverable targeting by tier/package/purchase.
  5. The lead-gen API is open by design (§3) — the same interface FN's devices use is the one a sponsor's AI-driven CRM enrichment or a third-party scanner vendor uses.

6. Enterprise foundation

Same platform backbone as the signage brief (keep the two consistent): managed Kubernetes (DigitalOcean DOKS) for the API/identity backbone, Cloudflare edge (DNS/WAF/TLS), GitOps delivery (ArgoCD), autoscaling and multi-replica services, HA managed MySQL with point-in-time recovery, container security scanning in CI. Sponsor-specific hardening on top: OAuth2 service-to-service calls behind circuit breakers with cached permission checks (graceful degradation), structured audit trails (ftn-audit) across services, OpenTelemetry instrumentation, and Sentry in the portal.

Positioning notes — accuracy guardrails (internal)

Keep these straight so we don't overclaim in an RFP or on a call:

  • "Booth Staff" is not a dedicated feature — it's a configured Page. There is no booth-staff route/module in the portal code; shows deliver it through the composable Pages system (a collection-module page gathering staff names). That's a strength to cite ("new sponsor workflows as configuration, no code") — but don't demo it as a purpose-built staff-management screen. A first-class booth-staff feature is planned (roadmap; don't sell it as shipped).
  • Leads are available in real time — do not say "released post-show." The old repo description says post-show release; no such gate exists in code. Real-time is the true (and better) claim.
  • Third-party scanner integration requires provisioning: an IDP client registration with the badge-scan scopes and a user token whose member is in the sponsor groups with a membership for that show. "Open, documented OAuth2 API" — yes. "Anonymous API key" — no. Frame the provisioning as tenancy/security, which it is.
  • Sponsor reporting is minutes-fresh (poll-sync + nightly reconcile), not live — and it rides RabbitMQ/polling, not Ably. Don't borrow the signage brief's real-time language for reports; reports are also internal/admin-facing in v1 (no customer-facing surface).
  • Stripe is the only functioning payment gateway (card + ACH via PaymentElement; ACH's async processing state is handled). LawPay exists only as a stub — don't claim multi-processor.
  • Invoice PDFs are generated client-side in the portal; the backend "invoice" is offline-payment metadata plus per-show wire-transfer instructions. Fine to say "branded invoice PDFs"; don't claim server-side invoice generation/emailing.
  • AI operates the platform via its APIs/data — there is no shipped "AI feature" in the product today. Same framing rule as the signage brief: AI-ready because the hooks exist (OpenAPI contracts, forms-as-data, event stream), not AI-does-it-today.
  • Minor stubs to avoid citing: iCal deadline export (commented out), cart-expiry countdown (behind an off-by-default flag).
  • No client/event names in external material — show manuals and template data carry real event names; keep them out.