Reconciliation

Reconciliation is a read‑only capability that allows clients to confirm which VET records exist in STARS, when they were last submitted and which version STARS currently holds without retrieving full record content, using change tracking identifiers.

It is primarily used so SMS suppliers and RTOs can:

• confirm data alignment between local systems and STARS,

• detect out‑of‑sync records by comparing change tracking identifiers, and

• confirm all data has been reported prior to completing a reporting period declaration.

Page contents:

Where reconciliation fits in the STARS lifecycle

Reconciliation is typically

• The starting point for validation and submission, by identifying which records in the local system are already reflected in STARS and which require submission or update. This includes the version of records using the change tracking identifier.

• An input into RTO and SMS reporting, enabling systems to produce reports that show which students and enrolments have been submitted to STARS, and which have not, for a given period.

• The first step in closing out a reporting period, by confirming the population of students and enrolments that STARS currently holds, so the RTO can assess whether its reporting for the period is complete and accurate.
  

Reconciliation supports the following basic lifecycle

1. Data is validated and submitted and accepted by STARS.
When validating and submitting records, the SMS may include a client-managed change tracking identifier to indicate the version of the record it is updating.

2. The current state of submitted data is reviewed using reconciliation.
Reconciliation returns key information about the data held in STARS, including the latest change tracking identifier for each record, representing the most recently accepted version.

3. The SMS or RTO user determines whether records require update, re‑submission, or no further action.
By comparing the locally stored change tracking identifier with the value returned by reconciliation, the SMS can identify records that are current, out‑of‑sync, missing from STARS, or incorrectly submitted and requiring corrective action.

Available reconciliation endpoints

Reconciliation can be applied in a small number of common patterns.

Period‑based reconciliation 

GET /vet-provider/v1/search-by-period

Used to review records for a defined date range or reporting period, supporting alignment checks and reporting period close‑out.

UID‑based reconciliation

POST /vet-provider/v1/uid-match

Used to target specific records and confirm whether particular resource identifiers exist in STARS and which version is currently held.

Related‑record reconciliation

GET /vet-provider/v1/{resource-type}/{uid}/related-resources

Used to confirm referential integrity between records, by checking which related top‑level resources are currently held in STARS for a given student or enrolment.

These end points allow SMS suppliers to apply reconciliation selectively, depending on whether they are validating completeness, targeting specific updates, or confirming relationships between records.

How reconciliation retrieval works

Reconciliation retrieval provides summary‑level visibility of records held in STARS. It is designed to answer existence, currency and alignment questions without returning full record content.

Query basis

All reconciliation queries are driven by student activity date, regardless of the resource type being queried.

This ensures reconciliation results reflect when training activity occurred, rather than when data was submitted.

Top‑level resources returned

Different reconciliation endpoints determine which top‑level resources are returned.

Search by period and UID match

The period‑based and UID‑based reconciliation endpoints return only the top‑level resource type that is queried.

Endpoints

• GET /vet-provider/v1/search-by-period

• POST /vet-provider/v1/uid-match

These endpoints do not return related or downstream resources.

Related‑record reconciliation

The related‑record reconciliation endpoint returns top‑level resources that are related to the supplied resource UID, based on established STARS relationships.

Endpoint

• GET /vet-provider/v1/{resource-type}/{uid}/related-resources

Related resources are determined by the traversal rules below, and will be returned where the relationships exist in STARS.

Only top‑level related resources are returned. Full record content is not included.

Relationship traversal rules (system behaviour)

For related‑record reconciliation, STARS returns top‑level resources that are related to the supplied resource UID by traversing established reference links between resources.

Traversal follows these rules

• Student → Enrolments
    * Student → Subject Enrolment
    * Student → Program Enrolment (where a direct link exists, or via Subject Enrolment where applicable)

• Student → Offerings / Programs
    * Student → Program Enrolment → Program Offering
    * Student → Subject Enrolment → Subject Offering → Program Offering
    * Student → Program Enrolment → Program Offering → Program
    * Student → Subject Enrolment → Subject Offering → Program Offering → Program

• Subject Enrolment → related resources
    * Subject Enrolment → Student
    * Subject Enrolment → Subject Offering
    * Subject Enrolment → Subject
    * Subject Enrolment → Program Enrolment (where linked)
    * Subject Enrolment → Subject Offering → Program Offering
    * Subject Enrolment → Subject Offering → Program Offering → Program
    * Subject Enrolment → Delivery Location (where linked)

• Program Enrolment → related resources
    * Program Enrolment → Student
    * Program Enrolment → Program Offering
    * Program Enrolment → Program

Data returned by reconciliation

Each reconciliation response returns a minimal metadata set for each resource, sufficient to support version comparison and alignment checks

• resourceUID

• resourceType

• submissionDateTime

The timestamp of the most recent successful submission for the resource (returned in UTC).

• changeTrackingIdentifier

The client managed version identifier for the latest submitted representation of the resource.

• studentActivityDate

• resourceInSubmission

Returned for UID‑based reconciliation only, indicating whether the resource exists in STARS.

Reconciliation always returns the most recent successfully persisted version of each matching resource.

Validation and result handling

• Structural validation is enforced on all requests, including
   
  * invalid or missing start and end dates
    * invalid date formats
    * more than 10 reporting period codes, and
    * unsupported resource types.

• Deleted resources are excluded from reconciliation results

• Duplicate records are not returned.

Sorting and pagination

• Results are sorted by
    1. Student Activity Date (newest to oldest), then
    2. Resource UID where dates are the same.

• Pagination is supported using
    * page number (default: 1; maximum 2147483647), and
    * page size (default: 10; maximum: 500).

Continue retrieving pages until all available results have been returned, rather than relying on a predefined maximum number of pages.

Example scenarios using reconciliation APIs

The following scenarios illustrate common ways SMS suppliers and RTOs use reconciliation APIs to verify data alignment, target specific checks and confirm related records held in STARS. These examples focus on typical usage patterns rather than exhaustive API behaviour.

Scenario 1: Period‑based reconciliation for alignment checking

Purpose

This scenario illustrates how an SMS uses period‑based reconciliation to review subject enrolment records for a defined activity window and confirm whether its locally held records are aligned with what STARS currently holds.

This scenario focuses on the normal (happy‑path) usage of reconciliation to support validation, reporting, and reporting‑period close‑out.

Scenario overview

The SMS queries STARS for subject enrolment records with activity dates between January and March 2026. STARS returns summary‑level metadata for each matching record, allowing the SMS to determine whether its local records are current, out‑of‑sync, or missing.

Preconditions

• The SMS is registered and authenticated to call STARS APIs

• The SMS has previously submitted subject enrolment records to STARS

• The SMS stores the change tracking identifier returned at submission time.

Sequence

Note: Security and authentication flows are not shown.

 Example request (search by period)

Records are filtered by student activity date, not by submission date.

Example response (summary-level)

Only top‑level subject enrolment resources are returned. Related records are not included in period‑based reconciliation.

How an SMS uses the result

For each returned subject enrolment:

• If the locally stored changeTrackingIdentifier matches the value returned by STARS, the record is current and no action is required.

• If the locally stored value does not match, the record is out‑of‑sync and may require re‑submission or correction.

• If a locally held record is not returned, it may not yet exist in STARS for the specified period and should be reviewed.
  This allows the SMS and RTO to assess whether subject enrolment reporting for the period is complete and aligned before proceeding with further submission or reporting‑period declaration.

Scenario 2: UID‑based reconciliation for targeted checks

Purpose

This scenario illustrates how an SMS uses UID‑based reconciliation to target specific records and confirm whether they exist in STARS for a given reporting period, and whether the locally held versions are current.

This scenario is typically used when the SMS already knows which records need to be checked and wants to verify their submission status and version alignment.

Scenario overview

The SMS submits a list of known resource UIDs and a reporting period code to STARS. STARS returns summary‑level metadata for each requested UID, indicating whether each resource exists in STARS for the specified period and, where present, the latest version held.

Preconditions

• The SMS is registered and authenticated to call STARS APIs

• The SMS has a known list of resource UIDs to verify

• The SMS stores change tracking identifiers returned at submission time.

Sequence

Note: Security and authentication flows are not shown.

Example request (UID match)

Example response (summary-level)

Only top‑level resources are returned. Related records and full record content are not included in UID‑based reconciliation.

How an SMS uses the result

For each requested UID:

• If resourceInSubmission is true and the locally stored changeTrackingIdentifier matches the value returned by STARS, the record is current and no action is required.

• If resourceInSubmission is true but the changeTrackingIdentifier does not match, the record is out‑of‑sync and may require correction or re‑submission.

• If resourceInSubmission is false, the resource does not exist in STARS for the specified reporting period and should be reviewed for submission.

This allows the SMS and RTO to perform targeted checks on known records without scanning an entire reporting period.

Scenario 3: Related‑record reconciliation for referential checks

Purpose

This scenario illustrates how an SMS uses related‑record reconciliation to retrieve top‑level resources related to a single known record and confirm whether those related records exist in STARS and are current.

This scenario is typically used to validate referential completeness for a student or enrolment prior to reporting or reporting‑period close‑out.

Scenario overview

The SMS submits a single resource type and resource UID to STARS. STARS identifies and returns summary‑level metadata for top‑level resources that are related to the supplied record, based on established relationship traversal rules.

Assumptions

This scenario assumes that

• Related‑record reconciliation returns only top‑level related resources

• Relationship traversal follows the rules documented earlier in this page

• Full record content is not returned.

Preconditions

• The SMS is registered and authenticated to call STARS APIs

• The SMS holds a valid resource UID to use as the starting point for reconciliation

• The SMS stores change tracking identifiers returned at submission time for related records.

Sequence

Note: Security and authentication flows are not shown.

Example request (related‑record reconciliation)

Note: The resource type and UID are supplied via the request path.

Example response (summary‑level)

Only top‑level related resources are returned. Full record content and non‑top‑level resources are excluded.

How an SMS uses the result

For each related resource returned:

• If the locally stored changeTrackingIdentifier matches the value returned by STARS, the record is current.

• If the value does not match, the related record is out‑of‑sync and may require correction or re‑submission.

• If an expected related record is not returned, the SMS can identify a potential completeness or referential gap and investigate further.
  This allows the SMS and RTO to confirm that related records are present and aligned in STARS, supporting confidence in reporting completeness and data integrity.