Most districts should begin with the standard Aeries/SIRAS behavior and review the results in Training. Do not require custom mapping up front. Use the optional mapping tools only when Training reveals a district-specific exception.
SIRAS uses the Aeries API to retrieve approved demographic, enrollment, school, language, and contact information. The opposite direction—SIRAS → Aeries—uses the Aeries Special Ed Data Import and is configured in Aeries–SIRAS Integration: Configure and Test Both Data Directions.
Contents
| What the API Can UpdateData authority, scope, and fields available to the integration. | Optional District PreferencesSettings that control how approved Aeries data is applied. |
| Contacts & Educational Rights HolderHow optional contact updating is processed. | New Records, 504 & TransfersOptional creation and matching safeguards. |
| Optional Mapping After TrainingUse only when a real local field, grade, school, or site exception appears. | Verify the ResultReview Training data and the API import log before Production approval. |
What the Aeries → SIRAS API Is Responsible For
For this integration, Aeries is the source for the approved enrollment, demographic, school, language, and contact information that the district has chosen to update in SIRAS. SIRAS remains the source for IEP, IFSP, ISP, 504, meeting, service, disability, program-setting, and other Special Education program information.
The Aeries → SIRAS process normally runs as part of the nightly demographic import. SIRAS retrieves records through the Aeries API and applies only the fields and preferences enabled for the district.
Review representative Training records before Production—especially contacts, identifiers, school mappings, grades, and locally maintained information.
Aeries API setup is maintained by Aeries
For the Aeries-side API Certificate creation and required permissions, use the vendor-maintained Aeries — SIRAS Integration instructions. Article 355 explains the SIRAS-specific credential-delivery and Training process.
Information SIRAS can update
| Aeries information | SIRAS result | Important behavior |
|---|---|---|
STU.ID | Local Student ID | Normally conditional for existing records unless the approved always-update preference is enabled. |
STU.CID | SSID | Normally conditional for existing records unless the SIRAS value is blank/invalid or the approved always-update preference is enabled. |
| School / reporting-school information | School Attending | Requires a valid school/site relationship in SIRAS. |
STU.ETH | Ethnicity | Standard Aeries behavior is used unless Training identifies a local exception. |
STU.RC1, STU.RC2, STU.RC3 | Race 1, Race 2, Race 3 | Standard mappings are assumed unless a local/nonstandard value is identified. |
STU.SX | Gender | Mapped to the corresponding approved SIRAS value. |
STU.HL | Native Language | Uses the Aeries Home Language Code. |
STU.LF | English Learner status / EL Type | Uses the Aeries Language Fluency Code. |
| RFEP information | RFEP Date | Updated when supplied by the approved Aeries source and mapping. |
STU.GR | Grade | Standard behavior is used first; document a local exception only when Training shows a mismatch. |
| Aeries track information | School Track | Applies where school tracks are used. |
| Residence information | District of Geographic Residence / School of Residence | Requires approved source fields and school relationships. |
| Future-school information | Next School / Next School of Residence | Optional. |
| District entry / enrollment history | District Enrollment Date | Optional processing rules are described below. |
Information not ordinarily overwritten on existing SIRAS records
- IEP, IFSP, ISP, 504, meeting, service, disability, program-setting, or other Special Education-specific data;
- student First Name or Last Name;
- Primary Residence Category;
- a valid existing SSID unless the approved always-update option is enabled;
- a populated Local Student ID unless the approved always-update option is enabled; and
- contacts when contact updating is disabled.
SIRAS does not ordinarily overwrite an existing First Name or Last Name from the Aeries demographic API. Preferred-name behavior and IEP-document naming decisions can differ from centrally maintained SIS values, so investigate discrepancies rather than assuming the API should replace the SIRAS value.
Optional District Preferences
These settings control how the Aeries data is applied after the connection is established. They are implementation choices—not a list of steps every district must enable.
| Preference | Recommended starting point | When to review it |
|---|---|---|
| Update demographics | Yes for the approved integration | Review the resulting values on the MIS Summary in Training. |
| Update contacts | No | New clients may test contact updates in Training and then decide whether Aeries or local SIRAS maintenance should control contacts. |
| Create new SIRAS records | No | Enable only after student matching, school routing, statuses, and Special Education program indicators are tested. |
| Create district transfer requests | No | Enable after the district confirms how records already located elsewhere in SIRAS should be handled. |
| Update Next School / Next School of Residence | No | Review when the district wants future-school information maintained through Aeries. |
| Update District Enrollment Date | Review during implementation | Confirm which Aeries source and processing rule the district expects. |
| Use enrollment-history data for District Enrollment Date | No | Enable only when the district wants the enrollment-history calculation described below. |
| Process 504 records | No | Enable only for districts using the SIRAS 504 module and after Program 101 behavior is reviewed. |
| Always update Local Student ID | No | Enable only when the district has confirmed Aeries as the continuing authority for that identifier. |
| Always update SSID | No | Enable only after identifier authority and matching risk are reviewed. |
District Enrollment Date
SIRAS can obtain District Enrollment Date using one of two approved approaches:
- District Enter Date: use Aeries
STU.DD. - Enrollment History option: when enabled, SIRAS may evaluate
END.EDrecords, consider qualifying records from the current academic year, exclude rows with a Leave Date, and select the earliest qualifying active district enrollment date before applying the approved SIRAS update rule.
Because local enrollment practices vary, review the result in Training before approving the option.
Aeries academic-year database
The Aeries API supports a DatabaseYear parameter using the year at the start of the academic year. For example, DatabaseYear=2026 represents the 2026–2027 database.
An incorrect/default database year can make grades, schools, statuses, or program indicators appear to come from the prior academic year.
Contacts & Educational Rights Holder Processing
Contact updating is optional. When enabled, the current Aeries → SIRAS processing rules include:
- Contacts identified in Aeries as Educational Rights Holders are prioritized.
- If one or more usable contacts are marked as an Educational Rights Holder, only those contacts are processed.
- If no contacts are marked as Educational Rights Holders, SIRAS processes the usable contacts returned by Aeries.
- A contact with no name, or no usable address, phone, or email information, may be skipped.
- If Aeries returns no contact records for the student, available student-address information may be used as a fallback.
For a new client, test this behavior in Training across several schools and different family/contact arrangements before deciding whether nightly Aeries contact updates should continue in Production.
Review the results under Student Info → Student Profile → Contacts.
New Records, 504 Records & Transfer Requests
New Special Education records
When new-record creation is enabled, the Aeries record normally needs:
- Program 144 for Special Education; or
- Program 144x when Aeries indicates that the student is being evaluated for Special Education services.
The current integration documentation identifies Program 144x when the Special Education record has no eligibility date and the evaluating flag is set.
504 records
When 504 processing is enabled, Aeries Program 101 may be used to identify records for the SIRAS 504 module.
SST records
The Aeries API does not provide a comparable SST indicator for this integration. SST records continue to be created and maintained in SIRAS through the district's normal process.
Matching safeguards
SIRAS attempts to match an Aeries student to an existing SIRAS record before creating anything new. If the identifying information is too similar to an existing record for safe automatic processing, the issue should be logged for review instead of creating a duplicate.
District transfer requests
When enabled, the integration may initiate a district transfer request when the matching record already exists in SIRAS at another district.
Optional Mapping — Use Only After Training Identifies an Exception
Run the standard Aeries → SIRAS configuration in Training first. Introduce a mapping override only when the district and SIRAS can point to a specific result that needs to be interpreted differently.
Use the Aeries–SIRAS Integration Configuration & Approval Workbook selectively to document exceptions. Do not store API keys, SFTP passwords, or other credentials in the workbook.
Examples of when mapping is useful
| Training result | What to document |
|---|---|
| A Kindergarten student appears as Infant, 12+, or another unexpected grade. | Document the district's actual Aeries grade value/code and the expected SIRAS grade. |
| A local ethnicity, race, language, or EL value produces an unexpected SIRAS result. | Document the actual Aeries value and the SIRAS result the district expects. |
| Several Aeries program/school names share one physical site or CDS code, but the district needs distinct SIRAS school identities. | Use the School & Site Mapping area to document the Aeries school/program identifiers and the corresponding SIRAS entities. |
| An Aeries school or status should not be processed. | Document the approved local exclusion/ignore rule. |
School and site mapping
When needed, the workbook can document:
- Aeries school code and school name;
- reported school code and optional site code;
- the corresponding SIRAS school and CDS code;
- whether the location should be processed or ignored; and
- multiple SIRAS entities associated with one Aeries campus.
Local field exceptions
The workbook's Default Mapping Review & Local Exceptions area contains standard comparison rows for identifiers, school values, ethnicity, race, English Learner status, language, grade, contacts, and other field behavior. Leave the standard/default behavior in place where it produces the correct Training result. Record an override only for the actual exception.
The specific exception is documented, SIRAS applies the revised rule in Training, and the district confirms that the affected records now display the expected result.
Verify the Result Before Production
After SIRAS runs the Aeries API import in Training:
- Review representative demographics on the MIS Summary.
- If contact updating is enabled, review Student Info → Student Profile → Contacts.
- Check examples from multiple schools, grades, and family/contact arrangements.
- Verify Local Student ID and SSID behavior.
- Confirm grade, school, race/ethnicity, language/EL, and District Enrollment Date where applicable.
- Go to Tools → SIRAS Admin → Scheduled Task Logs and review the current
api_import_log.csv. - Resolve or document material warnings/errors and retest any changed configuration or mapping.
Representative Training records match the district's expectations, optional mappings are limited to actual documented exceptions, and any material log issues have been resolved or assigned for follow-up.
For log interpretation, missing records, connection problems, status differences, credential changes, and established-integration issues, use SIS Integration Troubleshooting & Ongoing Monitoring.
