Event Information

WHEN

November 19, 2025 2PM ET/11AM PT

WHERE

GoTo Webinar

Join RunSignup CEO Bob Bickel and developer Duy Nguyen will dive into our Open API and MCP—how they empower developers and partners to build custom integrations and enhance the RunSignup. Additionally, get a sneak peak at how RunSignup MCP’s will make race data readily available within AI chat interfaces.

View Slides

RunSignup AI Application Library

Summary of Webinar

Big Picture

RunSignup has:

A mature API (since 2010) used heavily by:
- RunSignup RaceDay tools (Check-In, RaceDay Scoring)
- Third-party scoring/timing software
- CRMs (Salesforce, Blackbaud, etc.) via custom integrations
A philosophy of being an “open vendor”:
- Lots of endpoints for reading & writing race, participant, donation data
- Scales to millions of API calls (e.g., Thanksgiving)

This existing API is now the backbone for RunSignup’s AI and MCP work:

AI agents and chatbots can call the same APIs (via MCP) to:
- Read public/public-ish data (races, results)
- Read/write private data (participants, registrations) when authenticated

RunSignup API – Quick Primer

Two ways the API is used:

Pulling data (GET)
- Ex: RaceDay Check-In app asks: “Who are the participants for Race X?”
- Results listings, race calendars, CRM sync, etc.
Pushing data (POST/PUT)
- Ex: Check-In app posts: “Participant 123 is checked in; bib is 132.”
- CRMs ingest donations/fundraisers from RunSignup.

Two broad data classes:

Public API – Data that’s already public (e.g., race listing, public results).
Private API – Participant details, registrations, donations, etc.
- Protected via OAuth2 (modern auth standard).

MCP: How AI Talks to RunSignup

MCP (Model Context Protocol) = a standard way for LLMs (ChatGPT, Claude, Gemini, etc.) to call external tools / APIs.

Conceptual flow:

User asks in natural language:
“What was Joe Runner’s time in the Great Donut Race?”
LLM decides it needs RunSignup data → calls RunSignup MCP tool.
MCP talks to RunSignup’s Open API, gets JSON back.
LLM turns JSON → friendly answer:
“Joe Runner finished in 30:00, 26th place, 8:57 pace.”

RunSignup has:

Refined its API into an OpenAPI-compliant spec.
Wrapped it with:
- OAuth2 (incl. dynamic client registration / DCR)
- An internal MCP server that:
  - Knows which API to call
  - Returns useful structured data to the LLM
Early live usage: chatbots on event sites can already query results via MCP.

Dewey’s Demo #1 – MCP Inspector (Backend View)

Dewey showed how an LLM would reason, and then manually stepped through it in an MCP inspector:

Tools Exposed by the RunSignup MCP

Example tools:
- get_race_id (search race by name)
- search_event_results (results for a specific participant in a specific race)
- get_user_info, etc.

Example Query

“Retrieve the results for the Great Donut Race for the participant Joe Runner.”

Behind the scenes:

LLM wants to call search_event_results, but it needs a race ID.
It calls get_race_id with:
- Event name: "Great Donut Race"
MCP → API → returns metadata (including race ID: e.g. 4657).
LLM then calls search_event_results:
- Race ID: 4657
- First name: Joe
- Last name: Runner
MCP → API → returns a JSON record:
- Name, time, place, pace, etc.
LLM converts JSON into natural language:
“Joe Runner ran 30:00, 26th place, 8:57 pace.”

Dewey then showed the same interaction inside a ChatGPT dev environment where:

ChatGPT automatically:
- Selected the correct MCP tools
- Called them in the right order
- Combined the responses into a final answer

Dewey’s Demo #2 – Agentic Chat for Transactions

Second demo: chat-based registration/purchase on a TicketSignup-like event page.

Event: Holiday Drive-Thru Light Show
Tickets: “General Entry” and “Fast Pass”

Instead of using the normal form, Dewey used a chat widget:

Natural Language Cart Building

User:

“I would like to buy two of the cheapest tickets.”

The system:

Determines “cheapest ticket” = General Entry.
Adds 2 General Entry tickets to the cart.
Shows a price summary.

User:

“Actually, I want three.”

System updates cart to 3 tickets, recalculates total.

Collecting Registration Info via Chat

The chat then collects required fields:

First name
Last name (even from a natural phrase:
“My last name is Nenin.”
It extracts just "Nenin".)
Email

Payment – Secure Handling

User types something like:

“My credit card info is 4242… exp 01/26, CVV 737, ZIP 60601…”

Security model (critical point):

That message goes only to RunSignup’s own “agent” service, not directly to OpenAI.
On RunSignup’s servers:
- Sensitive data (card number, CVV, etc.) is sanitized:
  - Replaced with placeholders (tokens).
- A sanitized prompt is sent to the LLM:
  - e.g. {{CARD_NUMBER_TOKEN}}, {{EXP_TOKEN}}, etc.
LLM only sees the placeholders and decides:
- “Call the process_payment tool with these placeholders.”
Back on RunSignup’s side:
- The placeholders are replaced with the real card data from secure cache.
- Payment is processed entirely within RunSignup / Adyen infrastructure.
Result: No sensitive data ever leaves RunSignup’s environment.

The flow continues:

User is shown the standard waiver; they confirm.
Transaction completes:
- The system shows purchase ID, ticket details, confirmation codes, cost/fees/tax.
- The registration appears immediately on the dashboard.
- Confirmation email is sent as usual.

Security & OAuth2 / DCR

Key infrastructure pieces:

OAuth2 protects private data.
Dynamic Client Registration (DCR):
- When you’re in ChatGPT/Gemini in the future and first connect to RunSignup:
  - You’ll see a RunSignup login box.
  - You grant permission (like linking Google or Strava).
  - That session now has secure access only to your data.
The MCP server + OpenAPI spec ensure:
- AI tools can only call allowed endpoints.
- Rate limiting/scaling are handled properly.

Roadmap / What’s Coming

Short Term (Next 1–6 Months)

Continue building out the infrastructure:
- More MCP tools (beyond results & race lookup).
- Scaling for many concurrent chatbots & MCP calls.
Deliver a RunSignup-hosted, secure chatbot:
- Embedded in:
  - Event websites (participant-facing)
  - Race dashboards (director-facing)
- Initially for:
  - Participant questions (FAQ + live results)
  - Simple self-service actions (where safe)
Add RAG (Retrieval-Augmented Generation) and vector DBs to improve:
- Contextual answers based on docs, FAQs, help content.

Medium Term

On the front-end (participant side):

Chat-driven flows to:
- Sign up for events / buy tickets.
- Manage registrations (e.g., transfer from 10K to 5K) via chat.
- Get personalized info (e.g., “What’s my wave start time?”).

On the dashboard (director side):

Chat/agent interfaces for:
- Data analysis:
  - “Show a 5-year trend of under-30 participation”
  - “Graph revenue by event and price period.”
- Actions:
  - “Create a referral reward: $10 refund after 5 referrals.”
  - “Create a coupon for VIP Sponsors, $5 off, max 200 uses.”

Longer Term (As OpenAI/Google Evolve)

Full MCP integration with:
- ChatGPT “global” tool registry
- Gemini equivalents
Example future experiences:
- User in ChatGPT:
  “Find a marathon near Philadelphia in April and sign me up for the cheapest option under $100.”
  - ChatGPT uses RunSignup MCP → finds races
  - Uses Adyen’s MCP (or another payments MCP) for payment
  - Uses your saved profile (name, DOB, etc.) for registration fields
  - Confirms registration, sends email
- Race director in ChatGPT:
  “For my race ‘River Run 10K’, create a referral program: $15 refund after 3 referrals, cap at 300 total refunds.”
  - ChatGPT → RunSignup MCP → creates program and returns confirmation.

RunSignup’s plan is to:

Keep hosting the transactional logic + data (secure, PCI, etc.).
Use external LLMs as:
- Natural language front-end
- Reasoning engine to decide which tools / APIs to call
Continue aligning with OpenAPI, OAuth2, MCP standards so everything “just plugs in.”