Cómo encajan los programas, inscripciones, grupos, sesiones y asistencia en la API de Abler, y cómo representarlos en tu propio CRM, base de datos o herramienta de informes sin perder las relaciones importantes.
Dos caras del mismo modelo
Todo en Abler depende de dos cadenas de registros que terminan en una persona. Una describe la inscripción : quién se apuntó a qué. La otra describe la actividad operativa : qué se impartió realmente y quién participó.
Una Subscription te indica que alguien se ha inscrito en un programa.
La participación en eventos te indica en qué ha participado realmente esa persona.
Por tanto, el mismo usuario puede aparecer en ambos lados. El resto de esta guía repasa cada objeto uno por uno y después muestra cómo unirlos en tu propio sistema.
En la API, los programas se llaman Services
El primer punto de terminología que debes tener en cuenta: lo que la interfaz de Abler llama Program se representa en la API como Service. Fútbol U10, primavera 2026 es un programa desde el punto de vista del usuario, pero el objeto subyacente de la API es el Service.
En tu propio sistema, represéntalo como sea que llames a un programa o curso, y guarda el ID del Service de Abler como identificador externo. Así tendrás una clave estable con la que hacer coincidir las Subscriptions, Groups, Events y otros registros que lleguen después.
Los nombres cambian, y distintos programas pueden tener nombres idénticos. Usa los IDs de Abler para establecer todas las relaciones.
Los productos están por debajo de los programas
Un programa puede tener uno o varios productos asociados. La diferencia es, básicamente:
En qué participa alguien: Fútbol U10, primavera 2026.
Qué puede comprar o en qué puede inscribirse: las opciones de inscripción o de pago asociadas a ese programa, como Full Season o Monthly.
Que los productos necesiten sus propios registros en tu sistema depende de lo que necesites hacer. Si principalmente haces seguimiento de personas y participación, lo más importante es la relación entre programa y Subscription. Si también necesitas información comercial detallada, mantén también Product como un objeto independiente.
Una Subscription conecta a una persona con un programa
Una Subscription representa la inscripción o membresía de una persona en un programa. Contiene un serviceId, un productId y el userIdde Abler del usuario, junto con su propio ID único, estado, fecha de inicio, fecha de fin y fecha de creación.
→ El usuario 123 está inscrito en el programa 456 a través del producto 789.
En tu sistema, la Subscription se convierte en un registro de unión entre la persona y el programa: llámalo matrícula, inscripción o participación. Una persona puede tener muchas Subscriptions a lo largo del tiempo, y un programa tiene naturalmente muchos inscritos, así que la Subscription es lo que te indica quién está inscrito en qué.
Una Subscription no es lo mismo que la asistencia
Una Subscription te indica que una persona está inscrita en un programa. No te indica si asistió a cada una de sus sesiones.
Jane está inscrita en Fútbol U10, primavera 2026 , un programa de tres meses con 24 entrenamientos. Tu sistema debería tener una Subscription para la inscripción de Jane (en ocasiones más de una), luego 24 Events para cada sesión y, potencialmente, 24 registros de asistencia que indiquen si asistió a cada una.
La inscripción general.
Actividad en una fecha y hora concretas.
Mantener ambas cosas separadas es lo que te permite elaborar informes sobre inscripciones, participantes activos, frecuencia de participación, asistencia, retención, sesiones impartidas y compromiso por programa.
Los grupos conectan los programas con la actividad operativa
Cuando se configura un programa, los participantes se organizan en Groups. En algunas partes de la API también pueden aparecer como ageGroupId o un identificador de grupo equivalente. La actividad operativa normalmente se organiza en torno a los grupos: el programa Fútbol U10, primavera 2026 podría contener el grupo Entrenamiento U10 de los martes, y el grupo contiene los eventos que realmente se imparten.
No trates campos como productOption.groupIds como el vínculo definitivo entre un producto y su grupo operativo: pueden ser nulos y la relación puede cambiar en cualquier momento. Además, los programas pueden compartir grupos, y a menudo lo hacen; depende de cómo esté configurado el club.
Los eventos son actividades o sesiones individuales
Un Event es una actividad programada real: una ocurrencia dentro de la impartición de un programa.
Grupo Entrenamiento U10 de los martes
Eventos Mar 8 sep 17:00 · Mar 15 sep 17:00 · Mar 22 sep 17:00 · …
Por eso, un programa nunca debe asignarse como un Event en tu sistema. El programa es aquello en lo que alguien se inscribe; el Event es una sesión dentro de él. Guarda cada Event con su ID de Event original de Abler y, cuando esté disponible, conserva su identificador de grupo y el contexto del programa en lugar de depender solo del nombre del evento.
Los participantes de los eventos aportan la capa de asistencia
La última capa es el participante individual de un Event. Responde a quién participó en esta sesión concreta y, cuando se incluye información de asistencia, si asistió. Es una pregunta distinta de quién está inscrito en el programa, que se obtiene de las Subscriptions.
→ Subscription → Fútbol U10, primavera 2026
→ Participación en evento → Entrenamiento, 8 de septiembre
→ Participación en evento → Entrenamiento, 15 de septiembre
→ Participación en evento → Entrenamiento, 22 de septiembre
Es posible asistir a un Event sin tener una Subscription: las sesiones abiertas (drop-in) son habituales en algunos programas. Tu modelo debe contemplarlo.
No uses el ID de Subscription para conectar eventos con participantes
A veces puede aparecer información de Subscription junto a la participación en eventos, pero la integración no debe depender de que un Event Participant lleve un ID de Subscription fiable. La estructura más segura vincula cada hecho de forma independiente:
Después, obtén el contexto del programa a partir de Event → Group → Service.
Totalmente separado de la asistencia.
Así la inscripción y la asistencia se mantienen como hechos separados, lo que da un modelo mucho más limpio, y se cubren los casos en que un participante está en un Event sin una Subscription simple de uno a uno detrás.
El modelo completo
En conjunto, la estructura queda así. El lado de inscripción está a la izquierda, el lado de impartición a la derecha, y ambos se encuentran en el User y en el Service.
¿Quién se inscribió en qué programas? — Service + Subscription + User
¿En qué eventos participó realmente esa persona? — Group + Event + Event Participant + User
Asignación recomendada
Un punto de partida razonable para la mayoría de CRMs y bases de datos. Los nombres de tus objetos pueden seguir tu arquitectura actual; lo importante es conservar las relaciones.
| Abler | En tu sistema | Finalidad |
|---|---|---|
| UserProfile / User | Contacto / Persona | La persona |
| Service | Programa | El programa o actividad general |
| Product | Producto / Opción de programa | Oferta comercial opcional |
| Subscription | Matrícula / Inscripción | Conecta a una persona con un programa |
| Group / Age group | Grupo del programa / Cohorte | Agrupación operativa |
| Event | Sesión / Evento | Actividad individual impartida |
| EventPlayer / Participant | Asistencia / Participación en eventos | Conecta a una persona con un Event |
Guarda los IDs de Abler
Para cada objeto importado desde Abler, guarda el ID original de Abler como identificador externo, por ejemplo abler_user_id, abler_service_id, abler_subscription_id, abler_group_id, abler_event_id y abler_event_participant_id.
Esto permite que la integración haga upsert en lugar de crear registros nuevos en cada extracción, y simplifica la resolución de relaciones: cuando llega la Subscription 98765 con serviceId = 456, busca el programa donde abler_service_id = 456 y vincúlalo.
Orden sugerido para extraer los datos
Importa los registros padre antes que los hijos para que cada relación pueda resolverse al llegar.
1. Users
Crea o actualiza personas, conservando el ID de usuario de Abler
2. Services (programas)
Crea o actualiza registros de programas, conservando el ID del Service de Abler.
3. Products, si es necesario
Crea las opciones comerciales o de inscripción que quieras representar.
4. Subscriptions
Para cada una, usa userId para encontrar a la persona y serviceId para encontrar el programa. Así se crea la matrícula.
5. Groups
Extrae la estructura de grupos operativos, conservando el ID de Group / age group de Abler.
6. Events
Crea las sesiones individuales y asócialas con su grupo y su contexto de programa.
7. Event participants / asistencia
Para cada participante, vincula a la persona con el Event. Así obtienes el conjunto de datos de participación y asistencia.
Un ejemplo práctico
Service id 2001 · Fútbol U10, primavera 2026
Product id 2101 · Full Season
Subscription id 3001 · userId 1001 · serviceId 2001 · productId 2101
Group id 4001 · U10 martes
Event id 5001 · group 4001 · Entrenamiento U10 · 15 de septiembre
Event Participant user 1001 · event 5001 · Attended
→ Matrícula → Fútbol U10, primavera 2026 (desde la Subscription)
→ Asistencia → Entrenamiento U10, 15 de septiembre (desde el Event Participant)
Ambos se refieren a la misma persona, pero describen cosas distintas.
Por dónde empezar
En una primera fase, asegúrate de que estas relaciones son correctas antes de importar todos los campos que ofrece la API. Los identificadores críticos son el User ID (la persona), Service ID (el programa), Subscription ID (la inscripción de esa persona), Group / ageGroup ID (el grupo operativo), Event ID (una sesión individual) y Event Participant ID / User ID (la participación en esa sesión).
Una vez que los tengas, puedes añadir con relativa facilidad los atributos del programa, fechas, estado, datos demográficos, estado de asistencia e información de pagos.
No aplanes todo en un único objeto. Los programas, las inscripciones y los eventos tienen ciclos de vida distintos y relaciones de muchos a muchos diferentes. Piensa que Abler te ofrece dos conjuntos de datos relacionados, quién se ha inscrito en qué y en qué ha participado realmente , que juntos dan una imagen mucho más completa del compromiso que cualquiera de ellos por separado.