Ethos Egress: Occupancies (a.k.a. Housing Assignments)
Last updated: August 28, 2026
This document describes how Housing.Cloud can push Occupancies (a.k.a. Housing Assignments) to Ethos. It is expected that the Institution executed the proper due diligence to determine that the Ellucian Ethos API Models can satisfy their Institution specific Business requirements.
Banner Customers, please see additional information below the Housing Assignment content.
API Details:
- Endpoint:
/housing-assignments- Version:
application/vnd.hedtech.integration.v16+json
- Version:
- Required HTTP Methods:
POST,PUT, andGET
Housing Assignments Data Model:
| Field Name/Path | Required | Description |
| id | Yes | A null Ethos GUID value for POST and a valid GUID for PUT |
| person.id | Yes | A Profile's Ethos GUID |
| academicPeriod.id | Yes | Derived from the associated Cycle |
| room.id | Yes | A Room's Ethos GUID |
| status | Yes | Enum: assigned, prorated, canceled, terminated
|
| statusDate | Yes | The date in which the Egress API Request is executed |
| startOn | Yes | The start date of the Occupancy in Housing.Cloud |
| endOn | Yes | The end date of the Occupancy in Housing.Cloud |
| roomRates | No | Derived from the associated Bed Type of an Occupancy* |
| ratePeriod | No | Enum: day, term
|
Understanding Statuses:
The integration framework will derive on of the four Ethos statuses (assigned, prorated, canceled, and terminated) based on the Housing.Cloud status and the context in which the Occupancy was created/ended. Housing.Cloud has no control over the quantity of Ethos statuses.
It is the responsibility of the Institution to map the Ethos statuses to Colleague/Banner statuses and Special Billing Processes.
Default Status Logic:
-
assigned: The Occupancy was created normally, with a standard context -
prorated: The Occupancy was created normally, but an Admin prorated the Transaction associated with the Occupancy creation -
canceled: The Occupancy was ended normally, via the standard Cancellation Flow in Housing.Cloud- If the Housing.Cloud Occupancy has the status
Cancelled, then the Ethos statuscanceledwill be utilized
- If the Housing.Cloud Occupancy has the status
-
terminated: The Occupancy was end normally, via the Room Transfer or Swap Residency Flow in Housing.Cloud or marked explicitly marked as anEarly Terminationduring the Cancellation Flow- If the Housing.Cloud Occupancy has the status
TransferredorEarly Termination, then the Ethos statusterminatedwill be utilized
- If the Housing.Cloud Occupancy has the status
Custom Status Logic:
Housing.Cloud has the ability to customize how Housing.Cloud statuses are mapped to the Ethos statuses. The override logic is static and cannot change based on context.
- Example: All Occupancies with the
TransferredHousing.Cloud Status will utilize thecanceledEthos status, instead of the default status:terminated
Configuring Ethos Statuses to Banner/Colleague Statuses:
- Colleague configuration page:
VTHM - Banner configuration page:
SLRMSCD
Room Rates Derivation Logic:
The Room Rate GUID and Room Rate Period is derived by the following steps:
- For the Occupancy in question, the Bed Type in Housing.Cloud is obtained and the
External Room Rate Codeis parsed from the object - Housing.Cloud then polls the
room-ratesEthos API endpoint (No query arguments are supported for theroom-ratesendpoint for the code value)- For each response batch, Housing.Cloud attempts to match all of the following:
- The
External Room Rate Codein Housing.Cloud to the Room Ratescodevalue - Subsequent logic is dependent on the SIS:
- Banner: The Cycle's
External Idin Housing.Cloud to the Room RateAcademic Period Id - Colleague: The Room Rate with the latest active
startOndate that is less than or equal to the Occupancy Start Date
- Banner: The Cycle's
- The
- Once those two criteria are met, the Room Rate GUID is parsed out and we derive the Rate Period by using the following logic:
- If there is one valid Rate Period included in the Room Rate, then that period is utilized
- If there are multiple valid Rate Periods included in the Room Rate, then Housing.Cloud defaults to the
termrate period
- For each response batch, Housing.Cloud attempts to match all of the following:
Configurations:
These values can be set in the Integration Configuration Data Mappings object.
-
roomRatesRequired: If TRUE, theroomRatesandratePeriodattributes will be included in thePOSTpayload- Note: This is required for institutions that utilize the Billing features within Colleague/Banner
Banner Customers
During the Housing Assignment creation process, Banner requires an additional API call made to the Housing Requests endpoint.
Banner Configuration:
-
HEDM.ROOM.PERMIT.OVERRIDEsetting inGORICCRmust be set to:Y
API Details:
- Endpoint:
/housing-requests- Version:
application/vnd.hedtech.integration.v10+json
- Version:
- Required HTTP Methods:
POSTandGET
Banner Table:
SLBRMAP
Housing Requests Data Model:
This additional API request is only required for Banner
| Field Name/Path | Required | Description |
| id | Yes | A null Ethos GUID value for POST |
| person.id | Yes | A Profile's Ethos GUID |
| academicPeriods.id | Yes | Derived from the associated Cycle |
| startOn | Yes | The start date of the Occupancy in Housing.Cloud |