Skip to content

Integrations — Capability & AI-Readiness Brief

The integration story for the Foxtrot November platform, written for sales, solutions, and leadership use — specifically for prospects who want (or need) to keep an existing system of record. Grounded in shipped summit-api code (external registration/schedule feed framework, ingestion jobs, ticket-finder strategies) and the sibling briefs. Client/event/vendor names intentionally omitted in external copy.

Siblings: Platform brief · Sponsor Services · Digital Signage · Speaker Platform.

In one line

Keep your system of record — the venue still runs on FN. The platform was built on integrations, not just with them: external registration systems are a first-class, configurable data source, and because every FN experience is just an API client, any front end can be simulated by an integration script pulling from another system. And writing that script is exactly the job AI does in its sleep.

1. Built on integrations — not retrofitted for them

This isn't an integrations page; it's the platform's origin story:

  • External registration feeds are a summit-level setting in the core API: point a show at a supported external registration platform and a scheduled ingestion pipeline pulls attendees, tickets, and orders into the FN event model — with success/failure alert emails on every run. Externally-ingested attendees are recognized as such throughout the platform (their completion rules, identity anchors via external_id, and downstream behaviors all account for foreign provenance).
  • External schedule feeds have the same shipped framework — agenda data can originate outside and still drive every FN surface.
  • The venue stack doesn't care where the data came from. Badge scanning resolves tickets through a pluggable strategy chain that includes an external-feed resolver — so lead scanners, check-in, and badging work against attendees who registered somewhere else entirely.
  • The platform itself is a composition of integrations: payments (Stripe hosted fields), email (dedicated mail service), real-time (pub/sub with fallback), storage (S3 + Dropbox for on-site sync), social identity (Google/Facebook/Apple/Microsoft). Integrating is how FN is built, so integrating with FN is native motion, not an add-on SKU.

2. The deeper claim: any front end is an integration surface

Every FN application — event site, registration flow, CFP portal, admin console, signage screen, lead scanner, native app — is an OAuth2 client of the same API. There is no privileged internal pathway; the products use the doors integrations use. Which means:

  • Anything a front end does, a script can do. A nightly (or minutely) integration script that pulls from your system and writes to the FN API is indistinguishable from a user interface to the platform. Simulating "an app that syncs your attendees" is a page of code, not a product.
  • Both directions. Pull FN data out the same way: OpenAPI-described REST, filterable/paginated list endpoints, CSV exports, and a domain-event stream (message bus) for push-based sync.
  • Governed by construction: an integration registers on the IdP like every other client and holds exactly the scopes it's granted — tenancy enforced server-side (see the platform brief: AI gets a badge).

3. Why this is the AI moment (the headline)

Historically, the cost of "keep your system" was an integration project: weeks of vendor calls, mapping workshops, custom middleware. That cost has collapsed. Given two API contracts, AI can write, test, and iterate the bridging script in hours — and FN was built as the ideal far end of that bridge:

  1. Machine-readable contracts — services publish OpenAPI schemas; an agent reads what our own apps read.
  2. A data model designed for foreign keys — external_id anchors on the core entities exist precisely so another system can remain the source of truth.
  3. Configuration, not code, at the seams — feed types, field mappings, per-show behavior are settings.
  4. Idempotent, evented, observable — ingestion runs alert on failure; the event stream lets a bridge react instead of poll.

The pitch: bring your registration system, your CRM, your agenda tool — an AI-written integration script makes FN's entire venue layer (badging, signage, lead retrieval, deck distribution, check-in) light up on top of your data.

Positioning notes — accuracy guardrails (internal)

  • Named vendor adapters exist in code (registration: two commercial platforms; schedule: two agenda tools) — in external material say "supported commercial registration platforms" rather than naming them, unless the prospect asks; new adapters are the strategy-pattern extension point, an engineering task, not a product gap.
  • "Any front end can be simulated" is architecturally true (all apps are API clients) — but scope it honestly: a bridge script replicates data flows, not pixel-for-pixel UX. The claim is "your system stays the source of truth and FN's venue layer works," not "we clone your app."
  • A net-new external integration still needs provisioning: IdP client registration + scope grants, and (for a new vendor feed) an adapter. "AI writes the script in its sleep" refers to the bridging logic against our documented API — which is real — not to zero-effort onboarding.
  • Ingestion cadence is scheduled/job-based, and the event stream covers platform-originated changes; don't promise real-time bidirectional sync with arbitrary third-party systems.
  • Same standing rules: AI-ready (hooks exist, no shipped AI feature); no client/event names.