Release 8 (R8) - STARS go-live release notes

Page contents:

Release 8 (R8), the STARS go-live release, introduces the final core capabilities required to support the five business outcomes SMS suppliers need to enable:

  • Submit valid data

  • Reconcile previously submitted data

  • Remove data submitted in error

  • Check data quality

  • Make a declaration

R8 is both a Production and Client Integration Environment release. It enables SMS suppliers to progress through the production readiness self-assessment and continue integrating their solutions with STARS.

Once an SMS supplier has demonstrated readiness, its RTO clients can progress through the onboarding checklist.

Additional capabilities being released include the Classification API, replacing downloadable classification CSV files, validation and reporting period enhancements, and the introduction of jurisdiction in API routes.

Preparation to support Stage 2 development (STA system integration) has commenced. Jurisdiction is now required for transaction batch uploads and some related operations.

Some developer portal content has changed in line with the Release 8 build and will continue to evolve during Stage 2. SMS suppliers should account for additional functionality that will be introduced in future releases, particularly jurisdiction-specific validation and data quality behaviour.

Important:

Jurisdiction is now mandatory in transaction batch and selected top-level resource API routes. Existing routes without jurisdiction are no longer supported.

Scope caveat:

Data quality capability currently supports the NAT jurisdiction (national). Guidance will continue to evolve as Stage 2 capabilities are introduced.

Action required:

Review API routes, reporting period integrations, classification synchronisation and submitted-in-error workflows before implementation. Re-test affected integrations against the updated specifications and rules.

Breaking changes

Release 8 contains several changes that require SMS supplier system updates. Refer to the New and enhanced capabilities section for full details of these changes.

Jurisdiction in APIs

Jurisdiction is now mandatory in many API routes, parameters or request and responses bodies. SMS suppliers may need to update their integrations to supply the NAT jurisdiction (national) and allow for other jurisdictions in stage 2.

Reporting period model

The reporting period data model has changed. SMS suppliers should update affected integrations to use the new structure.

Submitted-in-error processing

Submitted-in-error requests must now include a reason when records are marked as voided. SMS suppliers should review and update affected workflows to meet the requirements.

New and enhanced capabilities

Jurisdictions are included in APIs

Jurisdiction is now mandatory in many API routes, parameters or request and responses bodies.

Key capabilities available in this release:

API routes now include jurisdiction. STARS stores jurisdiction against each transaction batch. The jurisdiction supplied in the route is checked against the transaction batch to help identify mismatches. Reporting periods now take the jurisdiction into account, establishing the foundation for future jurisdiction specific validation and reporting requirements.

Key supporting material:

  • Reporting Pathways guidance

  • Jurisdictions guidance

  • Updated OpenAPI Specifications

Important:

Developer Portal pages have been updated to accommodate the introduction of jurisdictions. New guidance introduces jurisdictions, jurisdictional reporting periods, validation and data quality concepts that will be progressively implemented as Stage 2 capabilities are introduced.

Submitted in error enhancements

Release 8 introduces updated submitted-in-error terminology and functionality.

Key capabilities available in this release:

Submitted-in-error processing now uses IsVoided and VoidedReason. Validation outcomes more clearly distinguish active records, previously voided records and records that cannot be found in the submission, while enhanced reconciliation support helps suppliers understand and manage the resulting record state.

Important changes:

  • AVETMISS data removal cannot be performed through STARS.

  • STARS supports voiding only for records that exist in submitted STARS data.

  • Child records must continue to be managed appropriately to avoid orphaning.

  • VoidedReason is mandatory whenever IsVoided is true.

Key supporting material:

  • Submitted in Error guidance

  • Updated Rules Catalogue

Review before implementation:

The Submitted in Error guidance now includes additional workflow guidance, validation outcomes and supported voiding scenarios.

Introduction of data quality checks

Release 8 introduces the first implementation of data quality assessment capabilities.

Note: only the optional contributing resources data quality result endpoint is available in this release. The summary endpoint will be provided in the next release.

Key capabilities available in this release:

SMS suppliers can use the new data quality assessment APIs to initiate and monitor organisation-wide data quality checks. Release 8 supports Validation and retrieval of failed validation results for 15 initial data quality rules.

Key supporting material:

  • Data quality guidance

  • Data quality API documentation

  • STARS Rules Catalogue

Review before implementation:

The STARS Rules Catalogue now includes data quality rules. Suppliers should review both the data quality guidance and STARS Rules Catalogue before implementation.

Scope caveat:

Data quality will continue to evolve to introduce additional rules and support state-based elements in future releases.

Classification API

A Classification Data API has been introduced. This capability replaces the previously available downloadable classification CSV files.

Key capabilities available in this release:

SMS suppliers can retrieve authoritative classification data through the Classification Data API. The API supports incremental synchronisation, timestamp based retrieval and pagination, enabling systems to identify and retrieve classification changes efficiently.

Key supporting material:

  • Reference and Classification Data API Usage Guide

  • Updated Data and Rules guidance

  • Updated Open API specifications

Action required:

All reference and classification data is now available through APIs rather than downloadable CSV files. Suppliers should review and update existing synchronisation processes accordingly.

Validation enhancements

Several validation framework enhancements have been introduced.

Key capabilities available in this release:

Release 8 also introduces an initial business validation phase, a data quality phase, and improves the overall validation performance.

STARS Rules Catalogue

The STARS Rules Catalogue has been significantly.

Key capabilities available in this release:

  • includes all data quality rules and identifies the 15 rules currently implemented

  • adds a Validation Results column to improve visibility of rule outcomes

  • clarifies that the Date of Birth Accuracy Code is not used when implementing the age-based rules BRDG00220, BRDG00176, BRDG00037 and BRDE00003

  • updates BRDG00147, BRDG00049 and BRDG00112 to use AUS Eastern Standard Time rather than UTC

  • updates the applicability requirements for BRTS90330

  • adds the new business rule BRTS90370.

Key supporting material:

  • Validation framework guidance

  • Updated STARS Rules Catalogue

Reporting Period enhancements

Release 8 introduces a redesigned reporting period model to support future jurisdiction specific requirements.

Key capabilities available in this release:

Reporting periods now use ReportingPeriodNumber and take the jurisdiction into account. The updated reporting period APIs also support enhanced declaration and reconciliation processing and provide the foundation for future jurisdiction specific requirements.

Action required:

Suppliers should review integrations that consume reporting period information and confirm compatibility with the new reporting period structure.

Known issues

Last reviewed: September 2026

Issues resolved since Release 5

  • VDS-34103: API OpenAPI specification spelling error

  • VDS-34113: Program Enrolment Transfer Validation

  • VDS-34126: Subject Enrolment Supersession Validation

  • VDS-33969: Student Transition Reference Data

  • VDS-32844: AuthenticationTokenIsExpired returns an incorrect TechnicalRuleId.

  • VDS-33838: BRTS08150 duplicate Subject Enrolment validation does not trigger in all supported scenarios.

Current known issues

Reference

Issue

Impact

Workaround

VDS-38925

Stub STARS APIs were delivered in R2, allowing SMS providers to explore the APIs in the CIN environment with mocked responses before they were fully delivered. In the Open API spec, the program enrolment API endpoints, and transaction batch - DELETE API endpoints are being displayed on Open API spec document. They should not be present.

The stubs are not as important now the real APIs are available to SMS providers to use in the CIN environment.

SMS suppliers can use the OpenAPI specification for API development and access the live APIs. These are available through the Developer Portal in the CIN environment, enabling them to validate their integration and test real API responses.

VDS-38945

Occupation reference data contains literal null values in ExtendedDescription.

Reference data inconsistencies may occur.

Expect an update to extended description. If you are mapping to NULL extended descriptions for any functionality, replace the string (null) with a NULL value.

Occupations without NULL extended descriptions are not affected.

VDS-39010

Program Level of Education reference values differ from previous releases.

Mappings of the Reference.ProgramLevelOfEducation enum used on /transaction-batch/{transactionBatchToken}/program to the reference data /reference-data/program using the programLevelOfEducation will break.

The enum Reference.ProgramLevelOfEducation should be mapped to the program reference data using programLevelOfEducation.
Any mappings using the ProgramLevelOfEducationValue were incorrect.
Use the correct mapping - no workaround required.

VDS-39232

Developer Portal stubs and scenarios are not displaying updated API responses in all cases. This includes the http status code (e.g. 201 instead of 200).

The impact is low.

The stubs and scenarios may not reflect the updated API responses.

SMS suppliers can use the Open API specification for API development and access the live APIs. These are available through the Developer Portal in the CIN environment, enabling them to validate their integration and test real API responses.