Understanding the Abler data model

Programs are called Services in the API

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.

Products sit underneath Programs

A Program can have one or more Products associated with it. The distinction is essentially:

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.

A Subscription connects a person to a Program

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.

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.

A Subscription is not the same thing as attendance

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.

Keeping the two apart is what lets you report on registrations, active participants, frequency of participation, attendance, retention, sessions delivered and engagement by Program.

Groups connect Programs with operational activity

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.

Events are individual activities or sessions

An Event is an actual scheduled activity — one occurrence in the delivery of a Program.

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.

Event participants provide the attendance layer

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.

Don't use the Subscription ID to connect Events to participants

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:

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.

The complete model

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.

Recommended mapping

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.

Store the Abler IDs

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.

Suggested order for pulling the data

Import parents before children so every relationship can be resolved as it arrives.

1. Users

Create or update people, retaining the Abler user ID

2. Services (Programs)

Create or update Program records, retaining the Abler Service ID.

3. Products, if required

Create the commercial or registration options you want represented.

4. Subscriptions

For each, use userId to find the person and serviceId to find the Program. This creates the enrolment.

5. Groups

Pull the operational Group structure, retaining the Abler Group / age group ID.

6. Events

Create the individual sessions and associate them with their Group and Program context.

7. Event participants / attendance

or each participant, link the person to the Event. This gives you the participation and attendance dataset.

A worked example

Both refer to the same person, but they describe different things.

Where to start

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.