FlowRunner
PricingContact
Theme
Start Free

HeySummit

Scheduling

Connect AI agents to HeySummit, a platform for virtual and hybrid summits. Agents register attendees, and read the events, talks, and tickets behind a summit as it fills.

9 actions API key available
HeySummit website ↗ Platform Documentation ↗ Capability data verified 2026-08-05
A scheduled run, because HeySummit exposes no webhook subscription endpoint
List Attendees filtered by event returns the registrants added since the last page was read
Each registrant is matched against the CRM so an existing contact is enriched rather than duplicated
List Talks resolves which sessions the summit is actually running, with the speakers embedded on each
The contact and the summit context are written into the marketing system that owns the follow up
The summit owner receives the registration curve by ticket type
A person confirms the consent basis before Create Attendee registers anyone from an outside list

What This Integration Enables

HeySummit hosts virtual and hybrid summits, and this connector is eight reads and one write. That ratio is the honest description of it and also the most useful thing about it, because it tells you where the risk is concentrated. The reads cover the whole object model of a summit. List Events and Get Event return the summits on the account, with boolean filters to narrow to live, archived, evergreen or currently open for registration events, which is exactly the set a scheduled flow wants rather than everything the account has ever run. List Talks and Get Talk return the sessions, and each talk carries its speakers embedded in a speakers array rather than behind a separate endpoint, so one call gives you the session and the people presenting it without a second resolution step. List Attendees and Get Attendee return registrants with their contact and registration detail, optionally filtered by event. List Tickets and Get Ticket return the ticket types and purchases behind the summit. Collections page at 100 items with a { count, next, previous, results } shape, and a flow follows the next URL or passes a page number to walk the rest.

The single write is Create Attendee, which registers a person for an event by name and email. Two boundaries around it are worth stating plainly before anyone builds on it. First, it adds the attendee to the event only, so booking them into specific talks is a separate concern this action does not cover. Second, and this is the one that shapes the whole page, adding an attendee assumes they have accepted the event terms and consented to receive event related emails. That is not a footnote about a checkbox. It is an assertion the API makes on your behalf about a person, and this connector exposes no action to remove an attendee once created.

There are no triggers here, because the HeySummit API does not expose a webhook subscription endpoint. Nothing in this connector registers a callback and nothing receives one, so reactive flows are scheduled polls of List Attendees scoped to the event that is currently open for registration. That is a cheap poll because the event filter keeps the set small, and the pagination shape makes an incremental walk straightforward. The read side is where this connector earns its place: a summit generates its most valuable data while it is filling, and pulling it out afterwards is why so much summit follow up arrives a week late to an audience that has already moved on.

Without FlowRunner

The registrant list lives in one place Summit registrations sit in HeySummit until somebody exports them after the event
Speaker promotion is untracked Nobody knows which speaker's audience actually produced registrations
Partner lists are imported by hand A co-marketing partner sends a CSV and somebody pastes it in

With FlowRunner

Registrants reach the CRM as they arrive List Attendees on a schedule feeds the marketing system while the summit is still filling
Talks and speakers travel with the registrant List Talks returns speakers embedded, so follow up can name the session somebody came for
Imports have a recorded decision behind them Create Attendee runs on a list a person approved, because registering someone asserts consent on their behalf

Use Case Scenarios

Registrants that reach the CRM while the summit is still filling

A summit opens registration six weeks out and the marketing team sees the list when it ends. The agent calls List Events with the open for registration filter to find the summit that is currently live, then List Attendees scoped to that event on a schedule, following the next URL to walk the pages. For each registrant it looks for an existing contact in HubSpot by email and updates it with the summit they registered for rather than creating a duplicate, and creates one where none exists. It calls List Tickets for the event so each contact carries the ticket type they took, which is the difference between a free registrant and somebody who bought an all access pass and should not receive the same nurture. Registration counts by ticket type go to the marketing channel in Slack daily, so the team can see the curve while there is still time to act on it.

Attributing registrations to the speakers who produced them

Summits run on speaker promotion, and nobody can usually say which speaker actually delivered. The agent calls List Talks for the event, which returns each session with its speakers embedded in the talk record, and builds the roster of speakers and the sessions they are presenting. It reads registration sources from the marketing side, where the promotional links each speaker was given carry their own campaign parameters, and joins the two so each registration is attributed to the speaker whose audience it came through. The joined picture goes to Google Sheets as registrations per speaker per talk, and a per speaker summary is emailed through Gmail to each presenter before the event, which is both a courtesy and the most effective possible nudge to promote again. Nothing is written to HeySummit in this flow.

A partner list that gets registered on purpose

A co-marketing partner offers to register their list for the summit. This is where Create Attendee comes in, and where the flow deliberately slows down. The agent reads the partner's list, deduplicates it against List Attendees for the event so people who already signed up are not registered twice, and normalises the names and email addresses. It then stops and puts the resulting list in front of the summit owner with the count, the source, and what registering them will assert. Only after approval does it call Create Attendee per person, at a pace that respects the API rather than in one burst, and it writes each created registrant into HubSpot tagged with the partner they came from so the co-marketing arrangement can be measured later. Where a registration fails it collects the failures rather than retrying blindly, because a retry against an API that has no delete action is how a list gets registered twice.

Human-in-Loop Highlight

Create Attendee is the gate, and the reason is written into its own documentation rather than inferred: adding an attendee assumes they have accepted the event terms and consented to receive event related emails. Every other action in this connector reads. This one makes a claim about a person's consent, and HeySummit then acts on that claim by treating them as a registered attendee of the event, with the event communications that follow from it. The asymmetry that turns this into a real gate is that the connector exposes no way to take it back. There is no delete or unregister action here, so an agent that registers the wrong list has produced a state it cannot reverse through the API, and the correction happens in the HeySummit dashboard by a person, after the first email has already gone. The situations where this matters are the ordinary ones. A partner shares their list on the understanding that both audiences opted in. A CRM segment is pulled with a filter that was right last quarter. A webinar attendee list from a different platform gets treated as summit interest. In each case an agent can see names and email addresses and cannot see the consent basis, because the consent basis does not live in any system it can read. So the flow assembles the import and asks for the one thing only a person holds. It posts to the summit owner: "Northwind sent 1,412 contacts for Ops Summit 2026. After deduplicating against List Attendees for this event, 1,196 are new. Create Attendee will register each of them and, per the HeySummit API, that assumes they accepted the event terms and consented to event emails. There is no unregister action in this connector, so undoing this means the dashboard and it happens after the confirmation emails. Confirm the consent basis for this list and I will run it, or I can create them as contacts in HubSpot instead and send them a registration link they click themselves." The second option is usually the right one, and the agent is not the right party to choose it. That is the human-in-the-loop moment in summit operations: an agent can prepare a clean list, and only a person can vouch for how it was gathered.

Agent processes routinely
Detects exception requiring judgment
Clear match Continues automatically
Ambiguous Routes to human via email
Human decides
Agent resumes with decision

Agent Capabilities

9 actions

Events

2
  • List Events Returns the summits and events on the account, with optional boolean filters for live, archived, evergreen and currently open for registration. The open for registration filter is what a scheduled flow uses to find the summit that is actually filling right now. Paginated 100 per page.
  • Get Event Returns the full detail of one summit by numeric ID, including its title, schedule and configuration.

Talks

2
  • List Talks Returns talks (sessions), optionally filtered by event and active status. Each talk includes its title, date, event, categories and an embedded array of speaker objects, so the session and the people presenting it arrive together rather than in two calls. Paginated 100 per page.
  • Get Talk Returns one talk by numeric ID with its schedule, categories and embedded speakers.

Attendees

3
  • List Attendees Returns registrants, optionally filtered by event, each with contact and registration detail. Paginated 100 per page with a `{ count, next, previous, results }` shape, so an incremental walk follows the `next` URL. This is the read a scheduled sync is built on, since there is no webhook to subscribe to.
  • Get Attendee Returns one registrant by numeric ID with name, email and event association.
  • Create Attendee Registers a new attendee for an event by name and email. This is the only write in the connector, and it adds the attendee to the event only, so booking them into individual talks is a separate concern. Adding an attendee assumes they have accepted the event terms and consented to receive event related emails, and no action here removes an attendee once created, which is why this runs behind an approval.

Tickets

2
  • List Tickets Returns tickets, optionally filtered by event, each describing a ticket type or purchase. The read that separates a free registrant from an all access purchaser before either one enters a nurture sequence. Paginated 100 per page.
  • Get Ticket Returns one ticket by numeric ID with its name, price and event association.

Frequently Asked Questions

What can FlowRunner do with HeySummit?

FlowRunner agents can run List Events, Get Event, and List Talks in HeySummit, plus 6 more actions.

Does connecting HeySummit to FlowRunner require OAuth?

No. HeySummit connects to FlowRunner with an API key, no OAuth flow required.

Can HeySummit trigger a FlowRunner workflow automatically?

HeySummit doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with HeySummit

$100 in credits. No card required. Connect in minutes.