FlowRunner
PricingContact
Theme
Start Free

Corsizio

Scheduling

Connect AI agents to Corsizio, an online event and class registration platform. Agents read events, attendee registrations, and account records, so a flow can act on new signups in the systems downstream of Corsizio.

5 actions API key available
Corsizio website ↗ Platform Documentation ↗ Capability data verified 2026-08-05
A scheduled run, because the Corsizio API is read only and publishes no webhook subscription endpoint
List Attendees filtered by registration date range returns the registrations added since the last run
Each registration is compared against the records already created downstream, so a re-read does not duplicate anything
Get Attendee Details with the payment data included confirms the money actually arrived
The roster, the invoice or the seat is created in the system that owns it, outside Corsizio
The programme coordinator receives the new registrations with their payment state
A person decides what a registration in a non standard state means before anything downstream acts on it

What This Integration Enables

The most useful thing to know about this connector is its boundary, so it goes first. The Corsizio public API is read only, and this connector exposes exactly what that API exposes: Get Account Details, List Events, Get Event Details, List Attendees and Get Attendee Details. There are no documented endpoints to create or update an event, to create or cancel a registration, or to move money, so no agent acting through this connector publishes a class, seats a student, refunds a card or emails a registrant. Corsizio owns the registration page and the payment, and the honest description of what FlowRunner adds is everything that happens one second after somebody clicks register.

That is a narrower surface than most integrations in this catalog, and it is also a cleaner one. A connector that can only read cannot corrupt the system of record, which means the scheduled poll at the centre of every flow built here can run as often as you like without a rollback plan. The reads are richer than the count of five actions suggests. List Events filters on status, date range, price range, category, location, age group, gender and level, with free text search on the event name or an exact event ID, and defaults to published events ordered by upcoming start date. List Attendees filters on event, registration date range, coupon code and one or more attendee statuses, with free text search on name, email or phone, and defaults to active registrations. Both support include and expand, which is where the depth is: an attendee can come back carrying its payment data, its activity history, its custom form field answers and the full event object, so a single read produces a record complete enough to act on rather than an ID to go and resolve.

There are no triggers here, because Corsizio documents no webhook subscription API. Reactive flows are built on a scheduled call to List Attendees with a registration date range that moves forward each run, which is the pattern the filters are clearly designed for. Get Account Details is the setup read: it returns the account's configured filter sets, the locations, categories, age groups, genders, levels and price ranges, and those IDs are what the List Events filters expect, so a flow resolves them once at design time rather than hard coding a label that an administrator can rename.

Without FlowRunner

Registrations are re-keyed Somebody exports a list from Corsizio and types it into the roster, the CRM and the invoice run
Payment state is checked by eye Whether a registration is actually paid is read off a screen, one row at a time
Non standard registrations get missed A refunded, waitlisted or partly paid signup looks like every other row in an export

With FlowRunner

Registrations are read on a schedule List Attendees with a date range window feeds every downstream system from one read
Payment state travels with the record Get Attendee Details returns the payment sub-object alongside the registration, so the two never separate
The odd ones surface as exceptions Registrations that do not match an expected status are held for a person instead of processed silently

Use Case Scenarios

A roster that builds itself in the system that owns it

A training provider takes course registrations through Corsizio and delivers them through a learning platform that has never heard of Corsizio. On a schedule the agent calls List Attendees with a registration date range covering the window since the last run and a status filter limited to active registrations. For each one it calls Get Attendee Details with the payment and details data included, which returns the contact information, the answers to the custom registration form and the payment sub-object in a single read. It creates the learner in the learning platform, appends the row to Google Sheets for the programme team, and creates or updates the contact in HubSpot with the course they enrolled on. Corsizio is not written to, because it cannot be. It is the source and the flow is the distribution.

Reconciling what was collected against what was delivered

Finance wants the month's course revenue split by event without opening the registration platform. On a monthly schedule the agent calls List Events for the period, then List Attendees per event with the payment data included, and joins the two into a per event picture of registrations, amounts, coupon codes used and payment states. The coupon filter on List Attendees is what makes discount analysis possible without exporting anything: a run per coupon code shows how much revenue each promotion actually moved rather than how many times the code was clicked. The joined output lands in Google Sheets and a summary goes to the finance channel in Slack. Nothing is corrected in Corsizio, and the summary says so, so nobody reads the report as a reconciliation that has already been applied.

Catching the registrations that do not fit the pattern

Most registrations are unremarkable and a few are not. The agent calls List Attendees each morning with a status filter set to the statuses that are not the ordinary active case, and for each result calls Get Attendee Details with payment and activity data included to see what actually happened to that registration and when. A signup whose payment sub-object shows less than the event price, a registration on an event whose start date has already passed, a record with an unexpected status: none of these can be repaired through this connector, so the agent does not try. It posts each one to the programme coordinator in Slack with the attendee, the event, the amount, the status and a link, grouped so a run of them reads as one problem rather than five. The coordinator fixes what needs fixing inside Corsizio, and the next scheduled read picks up the corrected record.

Human-in-Loop Highlight

The gate on a read only connector cannot be the write it does not have, and pretending otherwise would be dishonest. The gate is the first write that leaves Corsizio, and the specific thing a person is asked is a mapping question the API refuses to answer. List Attendees returns registrations carrying a status, and the filter accepts one or more of them, which means Corsizio holds more registration states than paid and not paid. Get Attendee Details with the payment data included returns what was actually collected against that registration. Neither call tells you whether a given combination counts as somebody who should be seated, invoiced, sent joining instructions or left alone, because that is a business decision the platform correctly declines to make on your behalf. And whatever the flow does next happens somewhere with real consequences and no Corsizio undo: a charge in Stripe, a seat in a course that has a physical room, a joining email that cannot be recalled once sent. So the mapping is confirmed by a person before it is applied, not inferred. The agent posts the first run's classification for approval: "Twelve registrations read from Corsizio for Level 2 Welding, starting 14 May. Nine are active with the full 340 EUR collected and I would seat and invoice those. Two carry a coupon and show 255 EUR collected, which matches the coupon value, so I would seat and invoice at the discounted amount. One is active with 0 EUR collected and no coupon. I cannot amend it in Corsizio and I do not know whether that is an offline payment already taken, a comp, or a failed card. Tell me what to do with that one, and confirm the rule for the other two groups so I can apply it unattended from next week." A person answers once, the rule holds, and the exceptions keep coming back. That is the human-in-the-loop pattern for a read only system of record: the connector guarantees nothing gets broken upstream, and the judgment goes where the irreversible action actually is.

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

5 actions

Account

1
  • Get Account Details Returns the authenticated account profile with its name, alias, time zone, currency, site URL and contact details, plus the configured filter sets used across events: locations, categories, age groups, genders, levels and price ranges. Run it once at design time to discover the IDs the event filters expect, rather than hard coding a label an administrator can rename.

Events

2
  • List Events Returns a paginated list of events, filterable by status, date range, price range, category, location, age group, gender and level, with free text search on the event name or an exact event ID. Defaults to published events ordered by upcoming start date. Use `include` and `expand` to enrich each event rather than resolving references in a second pass.
  • Get Event Details Returns the full detail of one event by ID, including schedule, pricing tiers, description, contact information and instructors. `include` adds filters, stats, attendees or payment data, and `expand` resolves referenced objects.

Attendees

2
  • List Attendees Returns a paginated list of attendees, which in Corsizio means registrations. Filter by event, registration date range, coupon code and one or more attendee statuses, with free text search on name, email, phone or an exact attendee ID. Defaults to active registrations. The registration date range filter is what a scheduled incremental sync is built on, since there is no webhook to subscribe to.
  • Get Attendee Details Returns the full detail of one registration by ID, including contact information, registration status, the answers to custom form fields, add-ons, coupon and feedback. `include` adds payment, activity or details data and `expand` resolves the full event or account object, so one call can produce a record complete enough to act on downstream.

Frequently Asked Questions

What can FlowRunner do with Corsizio?

FlowRunner agents can run Get Account Details, List Events, and Get Event Details in Corsizio, plus 2 more actions.

Does connecting Corsizio to FlowRunner require OAuth?

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

Can Corsizio trigger a FlowRunner workflow automatically?

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

Start building with Corsizio

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