Why We’re Introducing v2.5

For teams already integrated with v2, v2.5 is meant to make the platform easier to build against when educational data becomes more detailed, more contextual, and more operationally important.

v2 established a broad set of resources that made core district, school, person, class, calendar, and attendance workflows accessible through a consistent API surface. As integrations expanded, it became clear that some areas of the model needed more precision. In particular, attendance, scheduling, academic time structures, and enrollment context often require more nuance than a flatter or more generalized representation can provide.

v2.5 extends v2 to address that gap. The intent is not to replace the value of v2, but to provide a more complete and better-aligned representation of how educational activity is actually recorded and interpreted.

Why v2 Was Not Always Enough

Many integrations start with a straightforward need: identify students, enrollments, classes, calendars, and attendance outcomes. Over time, those same integrations tend to need more context:

• whether attendance was captured for a full day or a specific meeting
• how a status was entered, by whom, or from what source
• whether an attendance result carried additional flags or timing details
• how attendance relates to bell schedules, day rotations, grading windows, and calendar incidents
• how a person’s role changes depending on district, school, or class context
• how virtual or modality-specific metadata should be represented

In v2, some of this information could be inferred, flattened, or represented indirectly. That worked for simpler use cases, but it made more advanced use cases harder to support consistently across implementations.

What v2.5 Changes Conceptually

v2.5 introduces new API resources that provide a more structured model for educational operations, especially around attendance and academic context.

At a high level, the changes fall into a few themes.

1. Attendance becomes more expressive

Attendance is not just a single outcome. In practice, it often includes:

• different scopes, such as day-level versus period-level tracking
• multiple statuses and classifications
• flags and exceptions
• time intervals
• entry methods and sources
• support for virtual or modality-specific details

v2.5 gives these concepts a clearer home in the API. That makes it easier for integrators to distinguish between summary attendance and more operational attendance data, instead of relying on overloaded fields or implementation-specific interpretation.

2. Scheduling and calendars gain more operational context

Educational data is heavily shaped by time structures: school years, calendars, day rotations, bell schedules, and grading periods.

v2.5 improves how this context can be represented so that attendance, meetings, and enrollment-related activity can be understood in relation to the actual academic schedule. This is especially useful for districts and schools whose schedules are not uniform across campuses, terms, or days.

3. Enrollment context becomes more precise

A person’s relationship to an institution is not always captured well by a single generic enrollment model. Context matters at the district, school, and class level, and role information often changes depending on where that relationship is being evaluated.

v2.5 adds structure around those contextual relationships so integrators can build against a model that more closely matches real educational organizations.

4. The academic model becomes more unified

A major benefit of v2.5 is not just additional data, but better alignment across related data. Attendance, meetings, calendars, schedules, enrollments, and academic periods are modeled in a way that fits together more naturally.

That means less guesswork for developers when answering questions like:

• What does this attendance record actually apply to?
• What schedule or day structure was in effect?
• Which academic period or grading window does this belong to?
• What organizational context should this person or enrollment be interpreted within?

Why Developers May Care

For existing v2 integrators, v2.5 matters when your integration needs to do more than retrieve basic records.

It is especially useful if you need to:

• support more accurate attendance workflows
• distinguish daily attendance from meeting-based attendance
• preserve operational metadata instead of reducing it to a simplified status
• align attendance and enrollment data to academic calendars and schedules
• support districts with complex scheduling patterns
• reduce custom logic used to reconcile different attendance or enrollment interpretations
• prepare for reporting, intervention, analytics, or compliance use cases that need more context

In practical terms, v2.5 helps developers spend less effort inferring meaning from generalized records and more effort building directly against explicit representations.

How v2.5 Is Better Unified and More Flexible Than v2

The main improvement in v2.5 is that related concepts are modeled as related concepts, rather than being compressed into a smaller set of generalized resources.

That leads to a few concrete advantages:

• Better correctness: some information that could previously only be approximated can now be represented more directly. This reduces ambiguity and helps integrators avoid making assumptions that may not hold across districts or schools.
• Better extensibility: as institutions adopt more detailed workflows, the API model can represent them without forcing unrelated use cases into the same shape. This makes the platform easier to evolve while keeping the surface area coherent.
• Better interoperability across use cases: a richer shared model makes it easier for different applications to consume the same data for different purposes, whether the goal is operational sync, reporting, analytics, or user-facing experiences.
• Better replacement paths for older patterns: in some parts of v2, older fields or simplified representations may still work, but they are no longer the best fit for every scenario. v2.5 provides better representations where the older model was too coarse or too implicit. That gives integrators a clearer long-term path without requiring a breaking change.
• Compatibility and Adoption: v2.5 is intended as a non-breaking evolution of v2. Existing integrations should not need to rewrite their current implementations to remain functional. Instead, v2.5 creates an adoption path for teams that want access to richer educational data and better-structured API resources. Integrators can continue using the parts of v2 that already meet their needs while incrementally adopting v2.5 resources where additional detail or correctness is valuable. This is important because not every integration needs the same depth. Some use cases will remain well served by the simpler representations in v2. Others will benefit immediately from the expanded coverage in v2.5.