Understanding the Abler data model
Loading…
How programs, registrations, groups, sessions and attendance fit together in the Abler API — and how to represent them in your own CRM, database or reporting tool without losing the relationships that matter.
Everything in Abler hangs off two chains of records that both end at a person. One describes registration — who signed up for what. The other describes operational activity — what was actually delivered and who took part.
Registration
User→Subscription→Service
A Subscription tells you that someone has registered for a Program.
Operational activity
Service→Group→Event→Event Participant→User
Event participation tells you what that person actually took part in.
The same user can therefore appear on both sides. The rest of this guide walks through each object in turn, then shows how to bring them together in your own system.
1
The first terminology point to be aware of: what the Abler interface calls a Program is represented in the API as a Service. U10 Football, Spring 2026 is a Program from a user's perspective, but the underlying API object is the Service.
In your own system, represent it as whatever you call a program or course, and store the Abler Service ID as an external identifier. That gives you a stable key to match against when Subscriptions, Groups, Events and other records arrive later.
Never link records by name
Names change, and different Programs can have identical names. Use the Abler IDs to establish every relationship.
2
A Program can have one or more Products associated with it. The distinction is essentially:
Service
What someone is participating in — U10 Football, Spring 2026.
Product
What they can purchase or register for — the registration or payment options attached to that Program, such as Full Season or Monthly.
Whether Products need their own records in your system depends on what you need it to do. If you are mainly tracking people and participation, the Program and Subscription relationship is what matters most. If you also need detailed commercial information, keep Product as a separate object as well.
3
A Subscription represents an individual's registration or membership in a Program. It carries a serviceId, a productId and the user's Abler userId, along with its own unique ID, status, start date, end date and creation date.
User→Subscription→Service
Subscription { userId: 123, serviceId: 456, productId: 789 }
→ User 123 is registered for Program 456 through Product 789.
In your system the Subscription becomes a junction record between the person and the Program — call it an enrolment, a registration or a participation. One person can have many Subscriptions over time, and a Program naturally has many subscribers, so the Subscription is what tells you who is registered for what.
4
A Subscription tells you a person is registered for a Program. It does not tell you whether they attended individual sessions within it.
Jane is subscribed to U10 Football, Spring 2026 — a three-month Program containing 24 training sessions. Your system should hold one Subscription for Jane's registration (occasionally more than one), then 24 Events for the individual sessions and, potentially, 24 attendance records showing whether she attended each.
Subscription
The overall registration.
Event participation
Activity on a specific date and time.
Keeping the two apart is what lets you report on registrations, active participants, frequency of participation, attendance, retention, sessions delivered and engagement by Program.
5
When a Program is set up, participants are organised into Groups. In parts of the API these can also appear as an ageGroupId or equivalent group identifier. Operational activity is normally organised around Groups: the Program U10 Football, Spring 2026 might contain the Group U10 Tuesday Training, and the Group holds the Events that are actually delivered.
Service→Group→Event
Two things to watch
Do not treat fields such as productOption.groupIds as the definitive link between a Product and its operational Group — they can be null, and the relationship can be changed at any time. And Programs can, and often do, share Groups; this depends on how the club is set up.
6
An Event is an actual scheduled activity — one occurrence in the delivery of a Program.
Program U10 Football, Spring 2026
Group U10 Tuesday Training
Events Tue 8 Sep 17:00 · Tue 15 Sep 17:00 · Tue 22 Sep 17:00 · …
So a Program should never be mapped as an Event in your system. The Program is what someone registers for; the Event is one session within it. Store each Event with its original Abler Event ID and, where available, keep its Group identifier and Program context rather than relying on the Event name alone.
7
The final layer is the individual participant on an Event. This answers who took part in this particular session and, where attendance information is included, did they attend. That is a different question from who is registered for the Program — which comes from Subscriptions.
Event→Event Participant→User
Contact Jane Smith
→ Subscription → U10 Football, Spring 2026
→ Event Participation → Training, 8 September
→ Event Participation → Training, 15 September
→ Event Participation → Training, 22 September
Attendance without a Subscription is normal
It is possible to attend an Event without holding a Subscription — drop-in sessions are common in some programs. Your model needs to allow for it.
8
Subscription information may sometimes appear around Event participation, but the integration should not depend on an Event Participant carrying a reliable Subscription ID. The safer structure links each fact independently:
Attendance
Event Participant→User
Event Participant→Event
Then derive the Program context from Event → Group → Service.
Registration
Subscription→User
Subscription→Service
Kept entirely separate from attendance.
This keeps registration and attendance as separate facts, which is a much cleaner model, and it handles the cases where a participant is on an Event with no simple one-to-one Subscription behind it.
9
Put together, the structure looks like this. The registration side is on the left, the delivery side on the right, and both meet at the User and at the Service.
Registration view
Who signed up for which Programs? — Service + Subscription + User
Participation view
Which Events did that person actually take part in? — Group + Event + Event Participant + User
10
A reasonable starting point for most CRMs and databases. Your own object names can follow your existing architecture — the important part is preserving the relationships.
Abler | In your system | Purpose |
|---|---|---|
UserProfile / User | Contact / Person | The individual |
Service | Program | The overall Program or activity |
Product | Product / Program option | Optional commercial offering |
Subscription | Enrolment / Registration | Connects a person to a Program |
Group / Age group | Program group / Cohort | Operational grouping |
Event | Session / Event | Individual delivered activity |
EventPlayer / Participant | Attendance / Event participation | Connects a person to an Event |
11
For every object imported from Abler, store the original Abler ID as an external identifier — for example abler_user_id, abler_service_id, abler_subscription_id, abler_group_id, abler_event_id and abler_event_participant_id.
This lets the integration upsert rather than create new records on every pull, and makes relationship resolution simple: when Subscription 98765 arrives with serviceId = 456, look up the Program where abler_service_id = 456 and link it.
12
Import parents before children so every relationship can be resolved as it arrives.
Create or update Program records, retaining the Abler Service ID.
Create the commercial or registration options you want represented.
For each, use userId to find the person and serviceId to find the Program. This creates the enrolment.
Pull the operational Group structure, retaining the Abler Group / age group ID.
Create the individual sessions and associate them with their Group and Program context.
or each participant, link the person to the Event. This gives you the participation and attendance dataset.
13
User id 1001 · Jane Smith
Service id 2001 · U10 Football, Spring 2026
Product id 2101 · Full Season
Subscription id 3001 · userId 1001 · serviceId 2001 · productId 2101
Group id 4001 · U10 Tuesday
Event id 5001 · group 4001 · U10 Training · 15 September
Event Participant user 1001 · event 5001 · Attended
Jane Smith
→ Enrolment → U10 Football, Spring 2026 (from the Subscription)
→ Attendance → U10 Training, 15 September (from the Event Participant)
Both refer to the same person, but they describe different things.
14
For a first phase, get these relationships right before importing every field the API offers. The critical identifiers are the User ID (the person), Service ID (the Program), Subscription ID (that person's registration), Group / ageGroup ID (the operational group), Event ID (an individual session) and Event Participant ID / User ID (participation in that session).
Once those are in place, Program attributes, dates, status, demographics, attendance status and payment information can be added relatively easily.
The one thing to avoid
Do not flatten everything into a single object. Programs, registrations and Events have different lifecycles and different many-to-many relationships. Think of Abler as providing two related datasets — who has signed up for what and what did they actually take part in — which together give a far more complete picture of engagement than either one alone.