Enhancements to Registration Status API Endpoints for Improved Data Consistency and Usability

Summary:
While integrating with the iSAMS API, we identified inconsistencies and limitations in the Registration - Registration Status endpoints that hinder reliable data retrieval and system interoperability. This proposal outlines actionable enhancements to resolve these issues and improve the API’s functionality for all users.

Proposed Enhancements:

1. Align Data Consistency Across Endpoints

   • Issue: The endpoint [GET] /api/registration/register/{registrationPeriodId} returns multiple records for the same student/registration period, while [GET] /api/registration/register/{registrationPeriodId}/students/{schoolId} returns only one record.

   • Suggestion: Ensure both endpoints return identical data for the same parameters, or document the filtering logic (e.g., prioritization rules) applied to justify the discrepancy.

2. Introduce Unique Identifiers for Registration Records

   • Issue: No unique key (e.g., RegistrationStatusId) exists to distinguish between multiple records for the same SchoolId and RegistrationPeriodId.

   • Suggestion: Add a unique identifier field to each registration status record to enable reliable CRUD operations and data reconciliation.

3. Expose Time Range Data for Registration Records

   • Issue: Registration records reference time ranges (e.g., 14:25–15:29) that are not programmatically accessible via API fields, despite being visible in the UI.

   • Suggestion: Include StartTime and EndTime fields in the API response to align with the UI and clarify time-bound registrations.

4. Clarify Record Selection Logic

   • Issue: Ambiguity in how the API selects records when duplicates exist (e.g., which record is prioritized in [GET] /students/{schoolId}).

   • Suggestion: Document the logic (e.g., latest timestamp, priority rules for AbsenceCodeId) to ensure predictability for developers.

Benefits:

• Improved Integration Reliability: Eliminate risks of data mismatches in downstream systems.

• Streamlined Operations: Enable accurate updates/deletes via unique identifiers.

• Transparency: Clear documentation of endpoint behavior reduces development guesswork.

• UI/API Parity: Ensure API responses reflect UI data, including time ranges.

Supporting Examples:

Scenario 1:

• Endpoint 1: [GET] /api/registration/register/30070 returns two records for SchoolId=0736551639998.

• Endpoint 2: [GET] /api/registration/register/30070/students/0736551639998 returns one record.

• Need: Consistent logic across endpoints to avoid confusion.

Scenario 2:

• UI Registration Period: 15:15–15:59 (from Registration_Periods table).

• API Records: Reference time ranges (14:25–15:29, 15:30–16:00) not exposed in API fields.

• Need: Add StartTime/EndTime fields to explain these ranges.