Data import

Data import brings your existing records into 1Club from CSV files - usually when you move your gym over from another system or a spreadsheet. It runs as a four-step wizard: pick what you are importing, upload the file, review a validated preview, then execute. An AI analyzer can detect the record type and map your columns for you, so a file exported from another system usually imports without hand-editing the headers. You can import seven record types: members (contacts), memberships, plans, classes, bookings, invoices, and charges. Files must be CSV and up to 10 MB.

​

When to use it

Use import to start on 1Club with your history intact instead of re-keying members by hand. Nothing is written until you have seen a validated preview, only valid rows are imported, and re-running a file reuses existing members rather than duplicating them. Typical uses:

• Migrating members with their memberships - a padel and tennis gym imports one members file that also creates each member’s session-based membership, with sessions already used, and adds children as household dependents.
• Plans first, then the people on them - a martial-arts gym imports its belt-progression plans, then a members file that references those plans by name so each student lands on the right package.
• Carrying over class credits - a Pilates studio imports one-time class-pack memberships with the pack size, so their remaining class credits carry over.
• Bringing in past sales - a climbing gym imports its past day-pass charges, keyed by the member’s email.

See Worked example: migrating from a legacy system and Other vertical examples for the details.

​

The import wizard

Import lives under Settings > Data Tools > Import. The wizard has four steps, shown as a stepper across the top: Select Entity, Upload File, Preview, and Import.

​

Recommended import order

Because records reference each other, import them in dependency order. The wizard states it on the first step:

1. Members (contacts)
2. Plans
3. Memberships
4. Classes
5. Bookings
6. Invoices

Charges can be imported on their own or created as part of a chained member import. Before importing, make sure your Clubs, Areas, and Instructors already exist, because classes and bookings reference them by name or email.

​

Step 1 - Select entity

You have two paths on this step. AI-powered import. Upload a CSV into the AI card. The analyzer reads the headers and the first few rows, then proposes:

• the detected record type, with a confidence percentage,
• a short reasoning line explaining the detection,
• a set of column-to-field mappings, shown as "Your Column" -> field chips.

If the detection looks right, continue and the mapping is applied automatically. If it is off, you can still pick the record type manually below. Manual selection. Choose one of the record-type cards (Members, Plans, Memberships, Classes, Bookings, Invoices, Charges). Each card shows a short description of what it imports.

​

Step 2 - Upload file

If you uploaded through the AI card, your file carries over and the wizard notes it is already uploaded. Otherwise, upload the CSV here. Use Download Template to get a CSV with the exact expected column names for the selected record type; fill it in and upload it back. Only .csv files are accepted.

​

Step 3 - Preview

The preview validates every row against the selected record type without saving anything. You get three counts: Total Rows, Valid Rows, and Invalid Rows. Filter tabs let you view All, Invalid, or Valid rows, and each invalid row lists its specific validation errors. You can download the previewed rows (with their status and errors) as a CSV to fix them offline.

​

Step 4 - Import

Executing writes the valid rows to your organization. The results screen reports Total Rows, Imported, Skipped, and Errors, and lists the first several row-level errors if any occurred. Use Import another to start a fresh import. For membership imports, executing first opens a short dialog asking whether to mark the associated charges as paid. If you tick Mark as paid, you choose a payment type: Cash, Check, Bank Transfer, or Other.

​

Field mapping and templates

Each record type has a fixed set of expected fields. The template download gives you those exact column headers. Useful conventions the importer follows:

• Member name - use either name (a full name that is split into first and last) or firstName plus lastName. At least one is required.
• Custom fields - for member imports, any column whose header starts with custom_ is treated as a contact custom field automatically. Do not map those to standard fields.
• Tags - tags takes a comma-separated list, for example Open day, Lead. A tag that does not exist yet is created as a manual tag, so you do not have to set your tags up before importing. To tag a whole upload at once, put the same value in the tags column of every row.
• Dates - accepted formats are dd.MM.yyyy, dd.MM.yyyy HH:mm:ss, yyyy-MM-dd, yyyy-MM-dd HH:mm:ss, and ISO-8601. A row with an unparseable date is flagged in the preview.
• Charges default to paid, using your organization currency when none is given.

​

Chained member import

A member import is more than contacts. When the extra columns are present on a member row, the same row can also create related records in one pass:

• A charge - transactionAmount, transactionDate, transactionDescription, transactionPaymentStatus, transactionType, transactionCurrency, transactionTaxAmount, transactionTotalAmount.
• A membership - planName, membershipStartDate, membershipEndDate, membershipStatus, membershipPrice, membershipBillingFrequency, membershipAutoRenew, membershipSignupFee, plus session totals membershipMaxUses, membershipUsed, membershipUsesRemaining.
• A wallet credit - wallet, a decimal amount credited to the member’s wallet.
• Household dependents - dependent, a comma-separated list of dependent names (for example children or minors) added under this member’s household.

​

How duplicates are handled

Members are matched by email within your organization. If a row’s email already exists:

• The existing member is reused, not recreated.
• The charge, wallet credit, notes, tags, and custom fields on that row are skipped, so re-running an import does not double-charge or double-note anyone. This also means an import cannot add tags to members who are already in your organization - tag those from their profile instead.
• A membership or dependents on that row are still attached to the existing member. This is how you deliberately import several rows for the same member (one per membership) or add family members to an existing account.

Memberships themselves are de-duplicated by member, plan, and start date, so the same membership row imported twice is not duplicated.

​

Worked example: migrating from a legacy system

Suppose a padel and tennis club is moving off an old spreadsheet-based system and exports a members file, members.csv, with columns like Full Name, Email, Mobile, Join Date, Plan, Membership Start, Total Sessions, Sessions Used, and Kids.

1. Go to Settings > Data Tools > Import.
2. Drop members.csv into the AI-powered import card. The analyzer detects Members (Contacts) and proposes a mapping such as "Full Name" -> name, "Mobile" -> phone, "Join Date" -> createdAt, "Plan" -> planName, "Membership Start" -> membershipStartDate, "Total Sessions" -> membershipMaxUses, "Sessions Used" -> membershipUsed, and "Kids" -> dependent.
3. Confirm and continue to the Preview. Two rows are flagged: one has Join Date as 31/13/2023 (an impossible date) and one is missing an email. The counts read 48 valid, 2 invalid.
4. Download the invalid rows, fix the date and add the missing email in your source, and re-upload. The preview now reads 50 valid, 0 invalid.
5. Execute. Because these rows carry a plan and a start date, each member is created together with a session-based membership, and any names in the Kids column are added as household dependents under the parent. Session usage imports so remaining sessions are correct from day one.

Because members were matched by email, running the same file again would reuse every member rather than creating duplicates, and would only add memberships or dependents that were not already there.

​

Other vertical examples

• Martial arts gym - import a plans.csv first (belt-progression memberships with maxUses per grading block), then a members file that references those plans by planName so each student lands on the right package.
• Pilates and yoga studio - import class-pack memberships with membershipBillingFrequency set to one_time and membershipMaxUses for the pack size, so class credits carry over.
• Climbing gym - import transactions.csv of past day-pass sales keyed by contactEmail, leaving paymentStatus blank so they default to paid in your organization currency.

​

Tips and best practices

• Let the AI analyzer go first. It maps most legacy exports correctly, and you can still override the record type manually.
• Import in dependency order (members, plans, memberships, classes, bookings, invoices) so references resolve.
• Set up clubs, areas, and instructors before importing classes and bookings, which reference them by name or email.
• Use the preview as a linter. Download the invalid rows, fix them in your source file, and re-upload rather than editing inside 1Club.
• Re-running is safe for members. Email matching means a second run reuses members and only adds missing memberships or dependents.
• For member imports, prefix custom columns with custom_ so they map to contact custom fields automatically.
• Tag the batch as you import it. Add a tags column with the same value on every row (for example the source or campaign the list came from) so you can filter and message that group afterwards. Tags only apply to members the import creates, so do this on the first run.

​

Troubleshooting

​

Related