--- title: "RapidReg Integration" description: "Connect AI agents to RapidReg, a UK contactless registration platform. Agents read registrations as they are captured, along with the brands, items, and account records behind each event. The connector is read-only." url: https://flowrunner.ai/integrations/rapidreg date_modified: 2026-08-11T09:36:14-07:00 --- # RapidReg [Forms](https://flowrunner.ai/integrations/category/documents-forms) Connect AI agents to RapidReg, a UK contactless registration platform. Agents read registrations as they are captured, along with the brands, items, and account records behind each event. The connector is read-only. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 1 trigger · 4 actions · API key · available [RapidReg website](https://rapidreg.com/) · [Platform Documentation](https://rapidreg.com/developers) · Capability data verified 2026-08-05 1. On New Registration fires for a registration captured at a QR form 2. Agent reads the field\_data object with the submitted form values 3. Agent runs List Items to read the item's custom-field schema and its required flags 4. Agent matches the submitted details against the existing customer record 5. Agent writes the completed registration into the destination system 6. Agent posts captures that are incomplete or that match more than one customer 7. A person decides the identity match for any capture the agent will not guess at ## What This Integration Enables RapidReg is contactless capture, and the shape of this connector reflects that honestly. Someone scans a QR code at a counter, a gate, a class or a hire desk, fills in a form on their own phone, and the record lands. That is the whole job the platform does, and this connector reads the result rather than pretending to run the intake. All four actions are reads: Get Account returns the account behind the key with its name, contact email and timezone, List Brands returns the brands that group registration items with their subdomain and category, List Items returns the registration items along with the schema of custom fields captured during registration, and List Registrations returns captured registrations with a field\_data object holding the submitted values. Nothing in this connector creates or edits a brand, an item or a registration; those are created at the form, in the product. The event surface is a polling trigger rather than a webhook. RapidReg documents no webhook subscription API, so On New Registration works by fetching recent registrations each cycle and emitting any whose id has not been seen before, with the interval configurable down to thirty seconds and optional scoping to a single brand and item. That matters for how you design the flow. There is no decision surface inside RapidReg to write back to, which means every consequence of a capture happens elsewhere: in the CRM the customer record lands in, the waiver archive the signature is filed against, the class roster the booking joins. The agent's real work is turning a captured form into a correct write somewhere else, and knowing when it should not make that write on its own. ### Without FlowRunner **Captures batched and exported**: Registrations sit in RapidReg until someone runs an export at the end of the day **Required fields checked by eye**: A missing waiver field or contact detail is spotted only when the record is used **Identity matching done by hand**: Front desk staff decide which existing customer a walk-up registration belongs to ### With FlowRunner **Captures processed on arrival**: On New Registration fires per record and the flow starts within the polling window **Required fields checked against the schema**: List Items supplies the field definitions the capture is validated against **Ambiguous matches routed, clean ones written**: Confident matches flow straight through and the rest reach a named person ## Use Case Scenarios ### Walk-Up Registration to CRM A customer scans the QR code at a hire desk and completes the form. On New Registration fires, the agent reads field\_data, calls List Items to confirm every field the item marks as required actually came through, and searches the CRM for an existing contact on email and phone. A single confident match updates that contact and attaches the registration. No match creates a new one. The counter staff never open an export, and the record is in the CRM before the customer has finished at the desk. ### Waiver Completeness Sweep On a schedule, the agent runs List Registrations across a created-date range for the items that carry a waiver, reads each field\_data object, and compares it against the field schema from List Items. Captures missing a signature field, a date of birth, or an emergency contact are assembled into one list per brand rather than surfacing one at a time. The venue manager gets a single completeness report for the day instead of discovering a gap when the record is needed. ### Multi-Brand Roll-Up An operator runs several brands through RapidReg, each with its own subdomain and item type. The agent walks List Brands, then runs List Registrations scoped per brand across the same window, and appends the normalised results into a shared reporting view with [Google Sheets](https://flowrunner.ai/integrations/google-sheets) or [Airtable](https://flowrunner.ai/integrations/airtable). Volume by brand, by item and by day is assembled without anyone logging into each subdomain separately. ## Human-in-Loop Highlight RapidReg has no approval state, no status field and no write path, so a gate placed inside RapidReg would be theatre. The honest gate sits one system later, at the identity match. When a capture arrives with a name and a partial phone number that resolves to two existing customer records, or to a record whose email differs by a character, the agent has enough evidence to notice the problem and not enough to settle it. Merging into the wrong record attaches a waiver, a booking or a medical note to the wrong person, and undoing that in the destination system is far harder than pausing here. So the agent writes nothing. It posts the capture to the front desk channel with the raw field\_data, the required-field check it ran against List Items, and both candidate records side by side: "Registration 88214 on Kayak Hire, captured 14:06. Submitted as J. Alvarez with a partial mobile ending 4471. Two customer records match. Attach to Jorge Alvarez (last hire March), attach to Julia Alvarez (last hire yesterday), or create new?" A person picks. The agent then completes the write and records who chose. 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 4 actions ### Account 1 - **Get Account** Retrieves details of the RapidReg account associated with the API key, including the account name, contact email, timezone, creation date, and whether the account is active. Useful for verifying credentials and reading account settings. ### Brands 1 - **List Brands** Lists all brands configured in the RapidReg account. A brand groups related registration items and has its own subdomain, category, and item type. Returns each brand's id, name, subdomain, description, category, icon, and active status. Use a brand id to scope List Items and List Registrations. ### Items 1 - **List Items** Lists registration items (activities, events, forms, or bookings) in the RapidReg account, optionally filtered to a single brand. Each item includes its id, name, description, date type, owning brand, active status, and the schema of custom fields (name, type, required flag, description, and options) captured during registration. ### Registrations 1 - **List Registrations** Retrieves customer registrations captured through RapidReg forms, optionally filtered by brand, item, and a created-date range. Each registration includes its id, the item and brand it belongs to, the registration and duration timestamps, the created date, and a field\_data object with the submitted form values. Use the limit to cap how many records are returned. ## Triggers 1 triggers ### Event Triggers 1 - **On New Registration** Fires when a new customer registration is captured in RapidReg, optionally scoped to a specific brand and item. Each polling cycle fetches recent registrations and emits any whose id has not been seen before. Polling interval can be customized (minimum 30 seconds). ## Frequently Asked Questions ### What can FlowRunner do with RapidReg? FlowRunner agents can run Get Account, List Brands, and List Items in RapidReg, plus 1 more action. ### Does connecting RapidReg to FlowRunner require OAuth? No. RapidReg connects to FlowRunner with an API key, no OAuth flow required. ### Can RapidReg trigger a FlowRunner workflow automatically? Yes. RapidReg supports 1 trigger that can start a FlowRunner workflow automatically. **Work at RapidReg?** This integration exposes RapidReg to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/rapidreg. Site index: https://flowrunner.ai/llms.txt