The Aeries v5 API has been expanded with new endpoints and capabilities designed to support the Aeries Enroll Path integration, including the ability to search for students, transfer students between schools, manage medical history, immunizations, medical insurance, language assessments, student authorizations, free and reduced price meal records, parent survey responses, school supplemental data, upload documents, and track enrollment compliance — all through a secure, consistent REST API built on the v5 standard. This expansion is designed for district administrators who manage the Aeries Enroll Path integration.

From this article, you can:

• Review the prerequisites and security areas required for each endpoint
• Enable the v5 Enhancements feature flag that gates most new endpoints
• Reference the full set of new and extended endpoints, including request/response behavior and key constraints

To enable the endpoints described in this article, navigate to Admin > Feature Flags in Aeries and enable the v5 Enhancements flag; see Feature Flag Requirement for details.

Table of Contents ↑

Prerequisites and Security
Feature Flag Requirement
District-Wide Student Search
Inter-School Student Transfer
Medical History
Student Field Write Extensions
Language Assessment
Parent Portal Account Provisioning
Contact Comment Write Support
External Student IDs
Document Uploads
Document Confirmation Log
Other District Enrollments
Immunizations
Medical Insurance
Student Authorizations
Free and Reduced Price Meals Records
Parent Survey Responses
School Supplemental Data
Frequently Asked Questions

Prerequisites and Security ↑

Before using the v5 API enhancements, ensure the following are in place:

• The v5 Enhancements feature flag must be enabled for your district by Aeries Software Support. See Feature Flag Requirement for how to request activation.
• All requests require a valid AERIES-CERT certificate header.
• Each endpoint is protected by a dedicated API security area. A district administrator must grant the appropriate permissions to the Aeries Enroll Path integration on the API Security page in Aeries.
• After enabling the feature flag, the system may take up to 15 minutes to activate. You must log out and back into Aeries before changes take effect.

Feature Flag Requirement ↑

All v5 API enhancements are gated behind the v5 Enhancements feature flag, which is disabled by default.

District-Wide Student Search ↑

Overview

Search for students across all schools in a district before creating an enrollment record. This enables duplicate detection and ensures the correct workflow — new student insert vs. transfer — is triggered.

Endpoint

Query Parameters

Key Behaviors

• At least one search parameter must be provided. Requests with no parameters return HTTP 400.
• Results include active and inactive/transferred students across all schools in the district.
• Each result includes Guardian 1 and Guardian 2 contact information: first name, last name, relationship, home phone, cell phone, and email. Missing guardians return as null.
• Results are paginated using keyset pagination. Pass the nextKey value as the after parameter on subsequent requests.
• The grade field is returned as stored in Aeries (STU.GR). Pre-K grades follow the Aeries storage convention, where TK appears as -1 and PS as -2.

Security

Requires the District-Wide Student Search (qrySTU) security area with Read permission.

Inter-School Student Transfer ↑

Overview

Transfer an existing student from their current school to a destination school within the same district.

Endpoint

Key Behaviors

• The destinationSchoolCode field is required and must be an integer. enterDate, status, and grade are optional.
• The grade must fall within the destination school's configured grade range.
• The origin school record is not modified — no withdrawal is performed at the source school. If a withdrawal is required, that must be handled separately.
• If the student is already enrolled at the destination school, the request is idempotent and returns the existing record unchanged.
• Supports active students, inactive students, and previously returning students.

Security

Requires the Transfer Student Between Schools (cmdTrn) security area with Insert permission.

Medical History ↑

Overview

Create, read, update, and delete student medical history records (MHS table) via the v5 API. This allows the Aeries Enroll Path integration to write medical information collected during the enrollment process directly into Aeries.

Endpoints

Key Behaviors

• Invalid school codes return HTTP 404.
• GET returns records with resolved medical condition code descriptions. Each row includes PermanentID, SchoolCode, SequenceNumber, MedicalConditionCode, Date, ParentComment, and SchoolComment. The dedup key is MedicalConditionCode — one row per condition code per student.
• POST and PUT enforce field-level security and return the saved record on success.
• DELETE returns HTTP 204 No Content. Attempting to delete a nonexistent record returns HTTP 404.

Security

Requires the Medical History (MHS) security area. Read is available to all v5 API callers; Insert, Update, and Delete are used for writes.

Student Field Write Extensions ↑

Overview

Four additional student fields — previously unavailable via the API — can now be written during student insert and update operations.

New Writable Fields

Affected Endpoints

• POST /api/v5/schools/{schoolCode}/students — create student
• PUT /api/v5/students/{studentId} — update student (district-wide)
• PUT /api/v5/schools/{schoolCode}/students/{studentId} — update student (school-scoped)

Security

These are new writable fields on the existing student create/update endpoints, not a new endpoint or security area — access is governed by the same security area already required for those endpoints.

Language Assessment ↑

Overview

Support for Language Assessment (LAC) records, including Home Language Survey (HLS) data, state-specific fields, signature tracking, and audit fields. This enables complete language assessment data to be written to Aeries without manual entry.

Endpoints

Key Behaviors

• LAC is one-to-one with a student on permanent ID — there is only ever one record per student. GET returns a single object directly, not an array.
• Supports all LAC fields including core language codes (L1–L4), Texas-specific previous language (L5), California school entry date (STS), HLS date and completion tracking, and signature fields.
• GET returns HTTP 404 when no assessment record exists for the student. This is the normal "no assessment on file" signal, not an error — clients must handle 404 as a valid empty state.
• POST returns HTTP 201 Created on a new insert. POST returns HTTP 409 Conflict when an active LAC record already exists. Callers should treat 409 as informational (record already in place), not as a failure. Soft-deleted records are silently restored on POST (no 409 in that case).
• All fields are individually gated by resource-based authorization.

Security

Requires the Language Assessment (LAC) security area. Read is available; Insert, Update, and Delete are used for writes.

Parent Portal Account Provisioning ↑

Overview

When an API caller flagged as an Enroll Path Vendor Type inserts or updates a qualifying contact, the system automatically provisions a Parent Portal account for that contact — searching for an existing account by email, creating a new (or resurrecting a prior) account when none is found, and linking the student to that account. This eliminates the need for school staff to manually create portal accounts for parents. Provisioning is restricted to API callers whose Vendor Type is flagged as Enroll Path on the API Security page.

Provisioning Endpoints

Parent Portal provisioning uses three dedicated endpoints:

Provisioning Workflow

To provision a portal account for a contact:

1. Call the lookup endpoint to check whether a portal account already exists for the contact's email address.
2. If no account is found (HTTP 404), call the create-account endpoint to create or resurrect an account.
3. Call the link-student endpoint to associate the student with the portal account.

Provisioning Conditions

A contact is eligible for portal provisioning when all of the following conditions are met:

• The API caller's Vendor Type is flagged as Enroll Path on the API Security page.
• The contact has a valid email address.
• The contact is designated as the Primary contact.
• The AccessToPortal flag on the contact is set to true.
• The district's “Disable Portal Account Creation” setting must not be enabled.
• No portal account or access already exists for that email + student combination (prevents duplicates).

Key Behaviors

• Duplicate account creation is prevented — if a portal account already exists for the contact's email, no new account is created.
• All provisioning attempts are logged regardless of outcome.
• The email lookup route uses a query string (/accounts/lookup?email=) rather than a path segment, to avoid routing issues with special characters in email addresses.
• The link-student call is idempotent on (AID, StudentID) and returns HTTP 201 Created. The server checks HasAccess before linking to preserve portal-level authorization state.
• ActivationUrl in the create-account response is server-assembled. The raw portal confirmation code (PCC) is never returned to the caller.

Security

Requires the Parent Portal Account (PWA) security area with Read and Insert permission. Provisioning is additionally restricted to API callers whose Vendor Type is flagged as Enroll Path on the API Security page, regardless of other security area permissions granted.

Contact Comment Write Support ↑

Overview

The Comment field on student contact records (CON.ME) can now be written via the API on both insert and update operations.

Affected Endpoints

• POST /api/v5/students/{studentId}/contacts — create contact (Comment field now accepted)
• PUT /api/v5/students/{studentId}/contacts/{sequence} — update contact (Comment field now accepted)

Key Behaviors

• The Comment field maps to CON.ME in the Aeries database.

Security

Access is governed by the Contacts (CON) security area on the endpoint — there is no separate per-field gate, and the value is not silently ignored.

External Student IDs ↑

Overview

Create and read external student ID records (ESI table) via the API.

Endpoints

Key Behaviors

• The composite key (StudentID + SchoolCode + VendorName) must be unique. Duplicate keys return HTTP 409 Conflict.

Security

Requires the External Student IDs (ESI) security area with Read and Insert permission.

Document Uploads ↑

Overview

Upload documents and metadata, read and update metadata, and delete documents and metadata via the v5 API.

Endpoints

Key Behaviors

• Results are paginated using keyset pagination. Pass the after parameter with the last document sequence number to retrieve the next page.
• File size limits are enforced. Oversized files return HTTP 413.
• DELETE removes both the metadata record and the binary file content.
• HEIC files are silently converted to JPEG before storage. The Extension field in the response will reflect the converted type (jpeg), not the original (heic). This is relevant for uploads from iOS devices where HEIC is the default camera format.

Security

Requires the Student Documents (DOC) security area. Read is available; Insert, Update, and Delete are used for writes.

Document Confirmation Log ↑

Overview

Create and read document confirmation log records (DCL table) for compliance tracking.

Endpoints

Key Behaviors

• GET returns HTTP 200 with a JSON array when confirmation records exist. GET returns HTTP 204 No Content (empty body) when no records exist yet — clients must handle 204 as a valid empty-list state, not as an error.
• SequenceNumber is server-generated and appears in the response only. It is not a field callers can send on POST.
• Pagination is not required — confirmation records are scoped to a single student, which naturally limits the result set.

Security

Requires the Document Confirmations (DCL) security area with Read and Insert permission.

Other District Enrollments ↑

Overview

Full create, read, update, and delete support for Other District Enrollment records (ODE table).

Endpoints

Key Behaviors

• All operations follow standard Aeries API conventions for authentication, authorization, error handling, and response formatting.
• All fields are individually gated by resource-based authorization.

Security

Requires the Other District Enrollment (ODE) security area. Read is available; Insert, Update, and Delete are used for writes.

Immunizations ↑

Overview

Read existing immunization records and write vaccination dose records (IMM table) via the v5 API. This allows the Aeries Enroll Path integration to sync vaccination data collected during enrollment directly into Aeries.

Endpoints

Supporting Endpoint

Key Behaviors

• POST is bulk — one request carries the full vaccines[] array. The server returns per-vaccine outcomes in Outcomes[].
• GET returns { SchoolCode, StudentID, Outcomes: [...] }. Each entry includes a vaccine code and WrittenDoses — an ordered array of date or null per dose slot. Vaccines with no populated doses are omitted from the response.
• The dedup key is (Code, WrittenDoses[index]) — a specific dose slot on a specific vaccine.
• GET returns an empty array [] (not HTTP 404) when no immunization records exist for the student.

Security

Read on the Immunizations (IMM) security area is intended to be available to all v5 API callers regardless of the v5 Enhancements flag. A known issue currently causes this GET endpoint to return HTTP 501 Not Implemented when the flag is OFF; a fix is targeted for August 4, 2026. Until then, enable the flag to access this endpoint. Insert is required for POST.

Medical Insurance ↑

Overview

Create, read, update, and delete student medical insurance records (MII table) via the v5 API. This allows the Aeries Enroll Path integration to write insurance information collected during enrollment directly into Aeries.

Endpoints

Key Behaviors

• POST creates one MII row per call. Multiple policies per student are supported — each POST receives a fresh sequence number (MII.SQ).
• GET returns an array. An empty array [] means the student has no insurance records on file — this is a valid empty state, not an error. An invalid or nonexistent student returns HTTP 404 (Not Found).
• Medicaid Benefits ID (MII.MBI) is required when the Medicaid indicator (MII.MC) is set to Yes. A policy marked as Medicaid without a Medicaid Benefits ID is rejected.
• Callers should read existing records via GET before inserting to avoid duplicates. The server does not enforce a collision constraint.
• The server validates CarrierCode against a code list.
• Enroll Path currently uses GET and POST only. PATCH and DELETE are available in the full API.

Security

Requires the Medical Insurance Information (MII) security area. Read is available; Insert is required for POST.

Student Authorizations ↑

Overview

Create, read, update, and delete student authorization records (AUT table) via the v5 API. This allows the Aeries Enroll Path integration to write authorization data collected during enrollment directly into Aeries.

Endpoints

Key Behaviors

• One AUT row is created per authorization. Multiple authorizations per student require multiple POST calls.
• Callers should read existing records via GET before inserting to avoid duplicate rows on re-runs.

Security

Requires the Authorizations (AUT) security area with Read, Insert, Update, and Delete permission. (Generally available — not gated by the v5 Enhancements flag.)

Free and Reduced Price Meals Records ↑

Overview

Two endpoints support Free and Reduced Price Meals (FRE) data via the v5 API, each with distinct behavior. Use the correct endpoint for your workflow.

Route A — Income Eligibility (/free-and-reduced)

POST behavior: Closes the student’s current active record (sets its end date) and inserts the new one. Request shape uses the income-eligibility fields: Code (F/R/N), ParentIncomeLevel, SchoolCode, FamilySize, Source. SchoolCode and ParentIncomeLevel are required. Close and insert are two separate saves; the operation is recoverable by retry if interrupted.

Route B — General FRE Record (/free-reduced-records)

POST behavior: Plain insert — assigns a fresh sequence number and does not close any prior record. The caller is responsible for de-duplication: GET existing records and PATCH/DELETE the prior active row before inserting, otherwise repeated POSTs accumulate rows. Carries the full FRE field set including the decline fields.

Key Behaviors (both routes)

• Both routes are student-scoped only — there is no school code in the URL. FRE records are keyed by student permanent ID with no school code dimension.
• The GET response for Route B includes approximately 42 columns, including ApplicationDate, EffectiveStartDate, EffectiveEndDate, SchoolCode, and Source.
• The dedup key for Route B is ApplicationDate or EffectiveStartDate (year proxy).

Security

Read on the Free and Reduced (FRE) security area is intended to be available to all v5 API callers regardless of the v5 Enhancements flag. A known issue currently causes GET on both routes to return HTTP 501 Not Implemented when the flag is OFF; a fix is targeted for August 4, 2026. Until then, enable the flag to access these endpoints. Insert, Update, and Delete are used for writes.

Parent Survey Responses ↑

Overview

Create, read, and merge-update Parent Survey Response records (PRS table) via the v5 API. This allows the Aeries Enroll Path integration to write residence, military, and foster care survey data collected during enrollment directly into Aeries.

Endpoints

Key Behaviors

• This endpoint is student-scoped only — there is no school code in the URL. PRS rows are keyed on (ID, TY, SQ) with no school code dimension.
• The record type is specified in the request body (not the route) via the type discriminator: 1 = Residence, 2 = Military, 4 = Foster.
• PUT uses merge-fill semantics — only fields provided in the body are updated; omitted fields are left unchanged.
• This endpoint writes PRS rows only. It does not write PGM (Program) records — admin staff handle that downstream via the standard Aeries confirm flow.
• GET returns all non-deleted PRS rows, including confirmed (Status = 'C') rows. Confirmed rows are protected on update: a PUT against a confirmed row is rejected, so finalized responses cannot be overwritten.

Security

Requires the Parent Response to Survey (PRS) security area with Read and Insert permission.

School Supplemental Data ↑

Overview

Sparse-update per-school student fields via the v5 API. This allows the Aeries Enroll Path integration to write supplemental data to specific Aeries database columns without affecting other fields on the student record.

Endpoint

Key Behaviors

• Uses sparse PATCH semantics — only the columns specified in the request body are written. Omitted columns are untouched.
• Request body shape: { Columns: [{ ColumnCode, NewValue }] }.
• ColumnCode values correspond to Aeries database column codes (for example, STU.ID2). Contact Aeries to obtain the full list of writable column codes.
• Scoped by STU.ID (permanent ID), not the legacy STU.SN. The prior /UpdateSchoolSupplemental WebMethod that used SN still exists but is outside the Enroll Path permission bundle.

Security

Requires the Supplemental Data (SUP) security area with Update permission.

Frequently Asked Questions ↑

What happens if I call a v5 enhancement endpoint without enabling the feature flag?

The endpoint returns HTTP 501 Not Implemented. No data is read or written. Exceptions: Medical History, Student Authorizations, and the GET endpoints for Free and Reduced Price Meals and Immunizations are pre-existing, generally-available endpoints intended to remain available when the flag is OFF. (A known issue currently causes the Free and Reduced and Immunizations GET endpoints to also return 501 when the flag is OFF; a fix is targeted for August 4, 2026.) For Medical History and Student Authorizations, the flag additionally governs new Aeries code-value validation on Create and Update.

Who enables the v5 Enhancements feature flag, and how do I request it?

The flag is enabled by Aeries Software Support on a per-district basis; it is not a setting district staff can toggle themselves. Contact Aeries Software Support to request activation. Early access is currently limited to pilot districts.

How do I grant the Aeries Enroll Path integration access to these endpoints?

Navigate to the API Security page in Aeries and grant the appropriate security area permission to the Aeries Enroll Path API certificate. Each section above lists its required security area.

Does the student transfer endpoint withdraw the student from their current school?

No. The origin school record is not modified. If a withdrawal is required, that must be handled separately.

Can I search for students who are no longer active?

Yes. The district-wide student search returns both active and inactive/transferred students. The enrollmentStatus field in the response indicates the current status.

Is Aeries Enroll Path granted access to all of these endpoints automatically?

No. Each endpoint requires a specific API security area permission. District administrators control which security areas are granted to the Aeries Enroll Path integration on the API Security page. Parent Portal account provisioning is additionally restricted to API callers whose Vendor Type is flagged as Enroll Path on the API Security page.

Back to Top