Submit valid data

Submitting valid data is the process by which a registered training organisation (RTO) reports training activity data to STARS in accordance with the VET Information Standard (VET IS).

This outcome ensures that

• training activity data is accurately recorded in STARS, and

• the RTO meets its ongoing reporting obligations across a reporting period.

Unlike a single submission event, submitting valid data to STARS is an iterative process performed throughout the reporting period. It involves preparing, validating, and submitting data in cycles, as training activity occurs and as data is updated or corrected.

While STARS supports continuous, day‑to‑day reporting, RTOs must ensure that data is submitted at least quarterly to meet their reporting obligations under the Data Provision Requirements (DPRs).

Page contents:

Where submitting valid data fits in the STARS lifecycle

From a lifecycle perspective

1. Reconciliation is used to identify differences between local SMS data and STARS.

2. The RTO determines what needs to be:

   • submitted,

   • updated, or

   • corrected.

3. Data is prepared and uploaded to STARS in structured transaction batches.

   • A transaction batch may contain a single valid record or a large set of records with the same jurisdiction value.

4. On request, STARS applies validation rules and returns results.

5. Errors are resolved by RTO users and data re‑uploaded into the transaction batch as needed.

6. When valid, the data is submitted to STARS and the transaction batch is closed.

See Data and rules page for additional information about what "valid data" means, including information about reference data and business rules.

Available API endpoints

Submitting valid data is supported by a set of APIs that enable SMS vendors to create, manage, validate, and submit transaction batches to STARS.

These APIs cover the full submission lifecycle, including:

• reconciliation to compare records locally with STARS

• creating and managing transaction batches,

• uploading data for validation,

• triggering and retrieving validation results, and

• submitting validated data so it becomes part of the RTO’s reported dataset.

For complete endpoint definitions, request/response structures, and integration details, refer to the STARS API specification.

Simple and complex submission scenarios

Submitting valid data as an activity can range from straightforward uploads of clean data through to iterative cycles involving validation errors and corrections.

In a simple scenario, an SMS

• prepares a transaction batch (which may contain a single record or multiple records),

• uploads data to STARS,

• runs validation, and

• submits the data successfully on the first attempt.

In these cases, the data is already complete, structurally valid, and logically consistent, requiring minimal interaction beyond the standard submission flow. By using a minimal unit record, developers can achieve a simple valid data submission for their first time testing. See also scenario 1 below.

In more complex scenarios, the submission process becomes iterative. This commonly occurs where:

• data fails validation during upload or validation checks,

• business rules or VET IS constraints are not met, or

• logical inconsistencies exist between related records.

When errors occur:

• STARS returns validation results and error messages,

• RTO users need to review and correct the data in their SMS, and

• updated data is re‑uploaded and re‑validated within the same transaction batch.

This cycle may repeat multiple times until all issues are resolved and the data can be successfully submitted.
These scenarios highlight that submitting valid data is not always a linear process.

Scenario 1 - Basic workflow using the minimal unit record (MUR)

The minimal unit record (MUR) provides a recommended starting point for implementing the Submit valid data capability.

MUR “golden payloads” are guaranteed to pass blocking validation, allowing SMS vendors to focus on getting the core submission workflow working end‑to‑end before introducing more complex data scenarios.

This approach enables early verification that:

• transaction batches can be created and managed correctly,

• data can be uploaded and processed by STARS,

• validation services are functioning as expected, and

• successful submission can be completed and confirmed.

The MUR should be used as the first step in developing a client‑compatible integration with STARS.

Recommended MUR workflow

A basic MUR workflow follows the standard submission lifecycle, using a known‑valid payload.
See the MUR page for payloads.

1. Create a transaction batch
Initialise a transaction batch to contain the data to be submitted.

POST /vet-provider/v1/{jurisdiction}/transaction-batch

2. Upload MUR data entities
Upload the required entities (for example, Student, Subject, Offering, and Enrolment) into the transaction batch.
These entities are structured to meet the minimum requirements for first submission.

• POST /vet-provider/v1/{jurisdiction}/transaction-batch/{transactionBatchToken}/student

• POST /vet-provider/v1/{jurisdiction}/transaction-batch/{transactionBatchToken}/subject

• POST /vet-provider/v1/{jurisdiction}/transaction-batch/{transactionBatchToken}/subjectoffering

• POST /vet-provider/v1/{jurisdiction}/transaction-batch/{transactionBatchToken}/subjectenrolment

Equivalent endpoints exist for program-based MURs (Program, Program Offering, Program Enrolment).

3. Trigger validation
Request validation of the uploaded data.

MUR payloads are expected to pass all blocking validation rules.

POST /vet-provider/v1/{jurisdiction}/transaction-batch/{transactionBatchToken}/validate

4. Confirm validation results
Verify that no blocking errors are returned and the data is eligible for submission.

GET /vet-provider/v1/{jurisdiction}/transaction-batch/{transactionBatchToken}/validate

5. Submit the transaction batch
Submit the validated data so it becomes part of the RTO’s dataset in STARS.

POST /vet-provider/v1/{jurisdiction}/transaction-batch/{transactionBatchToken}/submit

6. Receive confirmation
Confirm that submission has succeeded and the data is now available for reconciliation and future updates.

GET /vet-provider/v1/{jurisdiction}/transaction-batch/{transactionBatchToken}

Transitioning beyond MUR

The MUR is designed for initial integration and testing only.

After establishing a working baseline, implementations should expand to handle

• incremental submissions referencing existing data in STARS,

• scenarios where validation errors occur and must be resolved, and

• more complex relationships between entities (for example, program‑linked enrolments).

At this stage, the submission process becomes more iterative and begins to reflect real‑world reporting behaviour, including error handling and reconciliation cycles.

Complex submission scenarios

Once the core submission workflow has been established using the minimal unit record (MUR), SMS suppliers should expand to support real‑world submission scenarios.

These scenarios introduce

• additional lifecycle states and transitions,

• more complex relationships between entities, and

• situations where validation, sequencing, and data dependencies must be actively managed.

Unlike the MUR workflow, these scenarios may involve

• multiple submissions over time,

• updates to existing records, and

• handling validation failures and partial success states.

To support this progression, the following scenarios illustrate common patterns for working with training activity data in STARS. Each scenario is documented separately and focuses on specific behaviours and considerations.

The following scenarios demonstrate how submission workflows evolve beyond first‑time registration and into ongoing data management:

• Scenario – Upload an enrolment
  First‑time submission of an enrolment and its related entities. Also known as registration.

• Scenario – Defer a program enrolment
  Updating lifecycle state to reflect a deferral.

• Scenario – Cancel an enrolment
  Handling enrolment cancellation and associated data updates.

• Scenario – Handle failures during lifecycle updates
  Managing validation errors and resolving issues across submission cycles.

• Scenario - Multiple blocking validation failure
  Demonstrates how a single validation rule execution can produce multiple related Validation Results.

Enabling automated submission

SMS suppliers may choose to implement automated workflows to submit VET IS data. Current policy settings do not prohibit automated submission, but SMS suppliers are responsible for confirming that these capabilities are designed and operated in line with RTO reporting obligations.

Regardless of submission method, RTOs retain full accountability for the accuracy, completeness and compliance of their data, and should have clear visibility and control over submissions.