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.
VoidedReasonis mandatory wheneverIsVoidedis 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.