We are introducing a set of API enhancements as part of our upcoming Unit Offer Unification release in Mid June 2026. These changes are designed to support more flexible relationships between Unit Offers, Course Offers, and elearning entities.
We have designed these changes to support backwards compatibility to prevent breaking existing API integrations. While most integrations will continue to work without immediate changes, some endpoints now return additional fields, nullable values, or updated relationship structures that may impact integrations relying on existing assumptions.
This article summarises the key changes, potential impacts, and recommended actions for customers using our API endpoints.
What is changing
Unit Offers Can Now Exist Independently
Previously, every Unit Offer was expected to be linked to a single Course Offer.
With this release:
- A Unit Offer can exist without a Course Offer
- A Unit Offer can be linked to multiple Course Offers
- New association endpoints have been introduced to manage these relationships
- Existing legacy fields remain temporarily available for backwards compatibility
What this means for integrations
If your integration assumes:
- every Unit Offer always has a Course Offer, or
- there is only ever one Course Offer relationship,
then your integration may need updating.
Recommended action
Move away from relying on legacy single-course-offer fields and instead use the new explicit relationship endpoints and relationship objects.
Key API Behaviour Changes
Several endpoints now allow Course Offer fields to return null.
Examples include:
- CourseOfferId
- CourseOfferCode
- CourseOfferDescription
- Relationships.CourseOffer
This occurs when:
- a Unit Offer has no linked Course Offer, or
- the relationship is now managed through the new linking model.
Recommended action
Update integrations to:
- safely handle null values
- avoid assuming these fields will always be populated
- use the new relationship collections instead
New relationship properties have been added, including:
- Relationships.UnitOfferCourseOffers
These provide the authoritative list of associations between Unit Offers and Course Offers.
Recommended action
Use these new relationship collections instead of legacy single-object relationship fields.
The platform now supports parent/child relationships between Unit Offers.
New hierarchy endpoints allow integrations to:
- retrieve parent/child relationships
- create hierarchical associations
- manage linked Unit Offers more flexibly
Recommended action
Ensure integrations tolerate additional relationship data appearing in responses.
Elearning Course Offers
Elearning Course Offers can now be associated through Unit Offers.
As part of this:
- CourseOfferId may now return null
- Relationships.CourseOffer may now return null
- some Course Offer metadata has been removed from Relationships.UnitOffer
Recommended action
Stop relying on nested Course Offer metadata inside Relationships.UnitOffer.
Instead:
- resolve Course Offer information through explicit associations
- handle nullable Course Offer fields safely
Elearning Enrolments
The CourseOfferIdFilter behaviour has changed.
It now includes:
- directly associated Course Offers
- Unit Offers linked to those Course Offers
Potential impact
Some integrations may receive broader result sets than before.
Recommended action
Review any filtering logic or downstream processing that assumes previous result behaviour.
The following fields have been removed from:
Relationships.UnitOffer
Removed fields:
- CourseOfferId
- CourseOfferCode
- CourseOfferDescription
Recommended action
Remove any dependency on these nested fields and retrieve Course Offer information through the new association model.
Unit Offer Endpoints
The following endpoints are affected:
- POST /unit-offers
- PUT /unit-offers/{id}
- PATCH /unit-offers/{id}
- GET /unit-offers/{id}
- GET /unit-offers
Important updates
- CourseOfferId is now obsolete in some request payloads
- CourseOfferId may be ignored during updates
- legacy Course Offer fields may return null
- multiple Course Offer links are now supported
Recommended action
Use the new linking endpoints instead:
- POST /course-offers/{id}/unit-offers
- POST /unit-offers/{id}/course-offers
What Is Not Changing Immediately
To support a smoother transition:
- many legacy fields remain temporarily available
- existing integrations using valid Course Offer links should continue working initially
- backwards compatibility has been retained where possible
However, these legacy behaviours should be considered transitional.
Summary of Impacted Endpoints
| Endpoint | Change | Mitigation to prevent break | Impact Probability | Potential Impact Details | Recommendations |
|---|---|---|---|---|---|
| POST /unit-offers | CourseOfferId in the request payload is now nullable and marked obsolete. Response Data.CourseOfferId, Data.CourseOfferCode, Data.CourseOfferDescription and Relationships.CourseOffer can now return null when the unit offer has no course offer link. New response property Relationships.UnitOfferCourseOffers has been added. | Temporary backwards compatibility remains: if a valid CourseOfferId is supplied on create, the unit offer-course offer link is still created automatically and existing course offer values are returned in relationships for now. | Low | Low immediate impact for existing create flows that still send a valid CourseOfferId. Future risk if integrations continue depending on obsolete fields or assume a single course offer relationship. | Update create flows to send CourseOfferId as null and create links via POST /course-offers/{id}/unit-offers or POST /unit-offers/{id}/course-offers. Read course offer associations from Relationships.UnitOfferCourseOffers instead of obsolete fields. |
| PUT /unit-offers/{id} | CourseOfferId in the request payload is now nullable and obsolete; any provided value is ignored. Response course offer fields can be populated from the first linked course offer, or null when no link exists. Multiple links return the first created link in legacy fields. | This endpoint already did not allow changing the course offer after creation, so ignoring CourseOfferId is not expected to break existing update behaviour. Legacy fields continue to be populated where a link exists. | Low | Potential break only for clients updating unit offers that are not linked to any course offers and expecting Data.CourseOfferId, Data.CourseOfferCode, Data.CourseOfferDescription or Relationships.CourseOffer to be non-null. | Stop sending CourseOfferId on update. Handle null legacy course offer fields and use Relationships.UnitOfferCourseOffers for association data. |
| PATCH /unit-offers/{id} | Response course offer fields follow the new linking model: populated when at least one link exists, first created link returned when multiple links exist, and null when no course offer link exists. | No existing behaviour for updating course offer association via this endpoint is being removed. Legacy response fields remain available for linked unit offers. | Low | Potential break for clients patching or reading unit offers with no linked course offers and assuming legacy course offer fields are always present. | Handle null Data.CourseOfferId, Data.CourseOfferCode, Data.CourseOfferDescription and Relationships.CourseOffer. Use Relationships.UnitOfferCourseOffers for full association data. |
| GET /unit-offers/{id} | Response course offer fields can now be null when the unit offer is not linked to a course offer. When multiple links exist, legacy fields return the first created link. New Relationships.UnitOfferCourseOffers exposes the associations. | Not a breaking change at release because existing linked unit offers continue returning legacy course offer values. | Low | May become breaking when clients start retrieving standalone unit offers and still assume legacy course offer fields are non-null or represent the only association. | Update consumers to tolerate null legacy fields and use Relationships.UnitOfferCourseOffers for course offer associations. |
| GET /unit-offers | CourseOfferIdFilter now searches across all course offers linked to a unit offer. Response legacy course offer fields can be null for unlinked unit offers or represent the first created link when multiple links exist. Relationships.UnitOfferCourseOffers is not included on this endpoint for performance reasons. | Existing linked records continue returning legacy course offer values. The filter still supports course offer-based retrieval using the new many-to-many association model. | Low | May affect clients that treat the list endpoint's legacy course offer fields as complete source-of-truth association data, especially for unit offers with multiple or no course offer links. | Use this endpoint for listing/filtering only. For exact course offer associations, retrieve the individual unit offer or use the new course offer-unit offer link endpoints. |
| All /unit-offers endpoints except GET /unit-offers | Two new response relationships are returned: Relationships.ParentUnitOffers and Relationships.ChildUnitOffers for managing unit offer hierarchy. These are excluded from GET many for performance reasons. | Fields are additive and should not break clients that ignore unknown response properties. | Low | Low risk unless strict schema validation rejects additional response properties. | Allow unknown response fields in clients. Use the new hierarchy endpoints for managing parent/child links. |
| GET /elearning-course-offers | Data.CourseOfferId is now nullable and Relationships.CourseOffer will return null when the elearning offer is linked to a unit offer. Relationships.UnitOffer no longer includes CourseOfferId, CourseOfferCode or CourseOfferDescription. CourseOfferIdFilter now returns direct CourseOfferId associations and UnitOffers linked to that CourseOffer. | Filtering remains backwards compatible by including both direct and linked associations. Nullability reflects whether the elearning offer is associated through a unit offer instead of a direct course offer. | Medium | Breaking for clients that require non-null Data.CourseOfferId or Relationships.CourseOffer. Breaking for clients reading CourseOfferId, CourseOfferCode or CourseOfferDescription from Relationships.UnitOffer. | Treat CourseOfferId and Relationships.CourseOffer as nullable. Stop reading removed course offer fields from Relationships.UnitOffer; resolve course offer associations through unit offer-course offer link endpoints where needed. |
| GET /elearning-course-offers/{id} | Same response model changes as GET /elearning-course-offers: nullable Data.CourseOfferId and Relationships.CourseOffer, and removed CourseOfferId, CourseOfferCode, CourseOfferDescription from Relationships.UnitOffer. | Same mitigation as GET many: response model supports the new association model where an elearning offer may be linked via UnitOffer rather than direct CourseOffer. | Medium | Breaking for clients assuming CourseOfferId/Relationships.CourseOffer are always present or using removed course offer fields under Relationships.UnitOffer. | Update deserialisation and business logic to support nullable course offer fields and resolve course offer information via unit offer associations if required. |
| POST /elearning-course-offers | CourseOfferId in the payload is now nullable. If both CourseOfferId and UnitOfferId are provided, UnitOfferId takes precedence and CourseOfferId is set to null. Response follows the GET /elearning-course-offers model changes. | Temporary backwards compatibility: requests that provide both fields still succeed by using UnitOfferId and nulling CourseOfferId rather than failing. | Medium | Potential break for clients expecting the response CourseOfferId to match the supplied CourseOfferId when UnitOfferId is also supplied, or clients assuming response course offer relationships are non-null. | When creating an elearning course offer linked to a unit offer, send CourseOfferId as null. Update response handling for nullable CourseOfferId and removed Relationships.UnitOffer course offer fields. |
| POST /elearning-course-offers/{id} | CourseOfferId in the payload is now nullable. If both CourseOfferId and UnitOfferId are provided, UnitOfferId is used and CourseOfferId is set to null. Response follows the GET /elearning-course-offers model changes. | Temporary backwards compatibility keeps requests with both values from failing by preserving UnitOfferId as the association source. | Medium | Potential break for clients expecting supplied CourseOfferId to be retained when UnitOfferId is also supplied, or clients relying on non-null/removed course offer fields in the response. | Send CourseOfferId as null when UnitOfferId is supplied. Update response parsing and downstream logic to support the new nullable/removed fields. |
| GET /elearning-enrolments | CourseOfferIdFilter now returns enrolments with a direct CourseOfferId association and enrolments associated through a UnitOffer linked to that CourseOffer. Relationships.UnitOffer no longer includes CourseOfferId, CourseOfferCode or CourseOfferDescription. | Filtering is broadened to preserve course offer-based lookup across direct and unit-offer-linked records. | Low | Breaking for clients using removed course offer fields under Relationships.UnitOffer. Result sets may include additional valid matches through unit offer links. | Do not read course offer fields from Relationships.UnitOffer. Review filter consumers for expected result scope and resolve course offer data through association endpoints if needed. |
| GET /elearning-enrolments/{id} PUT /elearning-enrolments/{id} PATCH /elearning-enrolments/{id} POST /elearning-enrolments | In response models, Relationships.UnitOffer no longer includes CourseOfferId, CourseOfferCode or CourseOfferDescription. | The removal aligns the response model with the new reality that a unit offer may have zero, one or many course offer links. | Low | Breaking for clients deserialising or reading those removed fields from Relationships.UnitOffer. | Remove dependencies on CourseOfferId, CourseOfferCode and CourseOfferDescription inside Relationships.UnitOffer. Use unit offer-course offer link endpoints or individual unit offer details where course offer context is required. |
| GET /unit-enrolments GET /unit-enrolments/{id} POST /unit-enrolments PUT /unit-enrolments/{id} PATCH /unit-enrolments/{id} | In response models, Relationships.UnitOffer no longer includes CourseOfferId, CourseOfferCode or CourseOfferDescription. | The response no longer attempts to represent a single course offer on UnitOffer because the association may now be zero, one or many. | Low | Breaking for clients using those removed fields from Relationships.UnitOffer. | Update clients to stop reading course offer fields from Relationships.UnitOffer. Resolve course offer associations explicitly via the new link endpoints or detailed unit offer retrieval. |
Recommended Migration Strategy
We strongly recommend customers:
1. Review Null Handling
Ensure integrations safely handle:
- nullable Course Offer fields
- nullable relationship objects
2. Stop Assuming One-to-One Relationships
Unit Offers may now:
- exist independently
- be linked to multiple Course Offers
Update data models and business logic accordingly.
3. Move to Explicit Relationship Endpoints
Use the new association endpoints for creating and managing links between entities.
4. Remove Dependencies on Deprecated Nested Fields
Several nested fields have either been removed or are now considered obsolete.
Overall Impact Assessment
For most customers, the immediate impact is expected to be low.
However, integrations are more likely to be affected if they:
- assume Course Offer fields are always populated
- rely on nested Course Offer metadata
- assume a Unit Offer can only belong to one Course Offer
- use strict response validation schemas
- tightly couple to existing relationship structures
Final Recommendation
Although the release maintains backwards compatibility where possible, customers should begin updating integrations now to align with the new relationship model.
Early adoption of the new endpoints and relationship structures will help avoid future compatibility issues as legacy behaviour is phased out.