Introduction

Release Notes

Stay up to date with the latest database view and schema changes in the Fortress API.

September 2026

Documentation & API Updates - September 1, 2026

Webhooks

New Documentation

  • message.received — Per-event payload reference for the newly published inbound-message event.

New Event

  • message.received — Delivered when an inbound message is received for a property your subscription covers. The data payload carries messageId, conversationId, propertyId, organizationId, customerId, prospectId, householdId, from, to, content, messageSid, and receivedAt. Field names match the Floo message and conversation resources where they overlap; messageId is the message resource’s id.

Changed

  • Webhook Events — message.received moves from “Defined, not yet published” to Available. The older two-way-messaging notification path is retired as of this change; this webhook is now the only notification Fortress sends for an inbound message.

Notes for Integrators

  • Delivery is at-least-once, the same as every other event — dedupe on eventId, never on messageId or on X-Fortress-Delivery-Attempt. See Idempotency.
  • customerId and prospectId are both null when the sender is not a recognized contact; at most one of the two is ever set.
  • message.received does not fire for an opt-out (STOP) or opt-in keyword reply, or when the receiving number does not match a property Fortress has on file. See When it does not fire.

August 2026

Documentation & API Updates - August 28, 2026

Webhooks

Documentation

  • Webhook Events — each event type now has its own page, starting with prospect.created. The combined event reference has been split so a new event adds a page rather than growing one.
  • Webhooks — new How a delivery works section, with a sequence diagram of a delivery and a worked example of the exact request your endpoint receives, headers included.
  • Webhooks — X-Fortress-Delivery-Attempt is documented as informational only. A value greater than 1 usually means an earlier attempt failed, but a redelivery of an already-delivered event also carries one, and the value can repeat across duplicates. Dedupe on eventId, never on this header.

Documentation & API Updates - August 26, 2026

Leslie Integration Settings

Changed

  • propertyLeslieConfigurations — secret values are now redacted on read. The settings object can carry a validation key; that key, and any other secret value inside settings, is write-only from now on — a GET never returns it.

Documentation & API Updates - August 25, 2026

Webhooks

New Documentation

  • Webhooks — Fortress now pushes signed event notifications to partner endpoints instead of requiring you to poll for changes. The new guide covers the delivery envelope, the X-Fortress-* headers, step-by-step signature verification with Node.js and Python examples, secret rotation, the retry and timeout rules, and idempotency requirements.
  • Webhook Event Reference — Per-event payload reference, starting with prospect.created.

New Event

  • prospect.created — Delivered when a new prospect is created for one of your properties. The data payload carries prospectId, propertyId, organizationId, phone, firstName, referralSource, isManual, and createdAt. Field names match the Floo prospect resource, so the same names mean the same things on GET /prospects/{prospectId} — prospectId is the resource’s id.

Notes for Integrators

  • isManual is true only when a person hand-entered the prospect in the Fortress UI, and false for a prospect created through the API, through an application conversion, or by an automated process. Bulk imports do not raise prospect.created at all, so isManual: false never tells you “this was an import” — that case is not observable from this event.
  • Subscriptions are provisioned by Fortress. There is no self-serve endpoint to create, list, or delete a webhook subscription — contact integrations@fortresstech.io with your HTTPS URL and the events you want.
  • A subscription is scoped to a single property, not to your organization. If you cover multiple properties, you have one subscription per property, each with its own signing secret — and each can point at a different URL if you want events for different properties delivered to different endpoints. This does not change the event payload: data.organizationId is still included on every event so you know which organization it belongs to.
  • Signatures are HMAC-SHA256 over exactly <t>.<rawBody>, hex-encoded, sent as X-Fortress-Signature: t=<unix seconds>,v1=<hex>. Verify against the raw request body bytes; re-serializing the parsed JSON changes the bytes and the digest will never match. Tolerance is 300 seconds.
  • During a secret rotation a second ,v1=<hex> is appended to the same header. Accept the delivery if any v1 matches the secret you hold, and loop over every v1 — reading only the first breaks intermittently during rotation.
  • Delivery is at-least-once, so you must dedupe on eventId, and you must respond 2xx within 10 seconds and do your processing asynchronously. 5xx, 408, 429, and transport errors are retried after the delivery queue’s visibility timeout; any other 4xx is treated as a permanent rejection, recorded, and is not retried. Redirects are not followed. The retry schedule and dead-letter behavior for a delivery that keeps failing are not finalized yet.
  • Events are not backfilled and bulk imports are suppressed, so webhooks are an ongoing-change feed, not a way to load initial state. A prospect your own integration created through the API does not generate a delivery back to you.
  • This is additive documentation. No existing endpoint, field, or schema changed.

Documentation & API Updates - August 19, 2026

Work Orders API

Schema Changes

  • POST /workOrders and PUT /workOrders/{workOrderId} — requestorEmail and requestorPhone are now explicitly nullable and accept a blank value. Sending an empty or whitespace-only string is treated as no value rather than rejected, which matches what the Fortress UI has always allowed when a work order is logged without requestor contact details. A non-blank value is still validated: requestorEmail must be a valid email address of at most 100 characters, and requestorPhone is still limited to 15 characters.
  • Work order responses — requestorEmail and requestorPhone are now documented as nullable. This corrects the published contract rather than changing behavior: both fields could already come back null, and a blank value submitted on create or update is now stored and returned as null.

Notes for Integrators

  • Blank and null are equivalent on input. Both mean “no requestor contact detail” and both persist as null, so a form that submits untouched inputs as empty strings no longer needs to strip them.
  • On update, omitting a field and sending null are not the same. Omitting requestorEmail leaves any stored value untouched; sending an explicit null — or a blank string — clears it. Send the field only when you intend to change it.
  • No field changed name or type, and neither field was ever required, so no existing integration needs to change. Clients that pinned a non-nullable type for these two response fields should widen it to accept null.

Documentation & API Updates - August 13, 2026

Screening API

Schema Changes

  • GET /screening-requests/{screeningRequestId} — screening.payload gains unit: the unit the screening is for, with id, number, and a nested floorplan object carrying the floor plan’s id, internalName and marketingName. Occupancy wins over the applied-for unit: whenever the household already occupies a unit, that is the unit reported, even when the application is for a different one. Only when the household occupies nothing does this fall back to the unit most recently assigned to the application, which is the usual case for a new applicant. A household part-way through a transfer reports the unit it still occupies, not the transfer destination, until the transfer completes.

Notes for Integrators

  • Both floor plan names are returned as separate fields. internalName is the name staff use inside Fortress — the floor plan endpoints expose this same value as name — and marketingName is the public-facing name. Either may be null independently.
  • Assigned units are not required in order to screen, so unit is null when the household has no unit assigned, and unit.floorplan is null when the unit has no floor plan. Neither case is an error.
  • unit is also null when the unit could not be resolved as the screening was submitted. That lookup is deliberately non-blocking so it can never fail a screening, which means a transient failure is indistinguishable from an unassigned unit.
  • The field is additive — no existing field changed name, type, or meaning.
  • unit is populated once when the screening is submitted and never recalculated, so it is absent entirely on screening requests created before this release, and a null is never backfilled afterwards. Treat a missing unit the same as null.

Documentation & API Updates - August 12, 2026

Messaging API

New Endpoint

  • PATCH /messages/{messageId}/needsHelp — Flag or resolve a message’s needs-help state. isFlagged: true raises the flag, isFlagged: false resolves it; the response echoes the message plus a rollup of the conversation’s needs-help state.

Schema Changes

  • GET /messages/{messageId} now exposes eight needsHelp* fields: needsHelp, needsHelpReason, needsHelpFlaggedByType, needsHelpFlaggedById, needsHelpFlaggedAt, needsHelpResolvedByType, needsHelpResolvedById, needsHelpResolvedAt. All are absent on messages that have never been flagged.
  • GET /conversations adds needsHelpMessageIds, the ids of every currently-flagged message on the conversation, and conversationStatus gains a new value, NEEDS_HELP. The status query parameter on GET /conversations accepts it too.

Notes for Integrators

  • NEEDS_HELP is a different signal from UNRESOLVED: it is per-message and typically agent-raised, versus UNRESOLVED’s thread-level staff triage. NEEDS_HELP prevails over the underlying workflow status for as long as any flag is open, and the conversation falls through to whatever status that workflow currently calls for once the last flag resolves.
  • The request is idempotent — flagging an already-flagged message, or resolving one that isn’t flagged, returns 200 with the current state rather than an error.
  • Flagging or resolving requires the update action on the messages permission scope. That grant is service-wide: it authorizes every write under /v1/messages/*, not only this endpoint.

This endpoint is part of our evolving API ecosystem. To explore availability for your integration, please contact our team.

Documentation & API Updates - August 11, 2026

Properties API

New Property Configuration Endpoints

  • GET /properties/{propertyId}/configuration — The extended configuration record for a property: marketing copy, contact routing, resident-facing links, leasing and application settings, master metered utilities, service vendors and site details. Roughly 60 fields that were previously unavailable through the API.
  • GET /propertyConfigurations/{propertyConfigurationId} — The same record as a bare object rather than an array. A property’s configuration id is the same as its property id.

What the record covers

  • Marketing — propertyDescription, shortDescription, officeHoursDescription, officeHours, petPolicyDescription, parkingDetailDescription, amenities, marketingUrl.
  • Contact — email, phone, faxNumber, and textingPhoneNumber for properties with two-way communication enabled.
  • Address — the physical address, with physicalState resolved to a two-letter code.
  • Links — availabilityUrl and applicationPortalUrl.
  • Leasing and applications — lateFeeMethod, acceptingOnlineApplications, applicationIncomeRequirement, allowedLeaseTermMonths, quoteExpiration.
  • Utilities — masterMeteredElectricity, masterMeteredGas, masterMeteredSewer, masterMeteredTrash, masterMeteredWater, masterMeteredOther.
  • Security deposit interest — accrueSecurityDepositInterest, securityDepositInterestPayoutFrequency, securityDepositSimpleInterestRate.
  • Geography and time — nearestMetroArea, timezone, goesOnDaylightSavings, countyName.
  • Lifecycle dates — siteBuiltDate, lastRenovationDate, managementTookOverDate, acquisitionDate, managementQuitDate.
  • Site details — officeAlarmCode, hasGateWithCode, hasFitnessCenter, hasPool, hasPackageDelivery, nonSmoking, petWeightMax, leadPaintDisclosure.
  • Contacts and vendors — clientRepresentativeName, accountantName, apClerk, and the water, gas, electric, cable, internet, pest and trash companies.
  • Fees and periods — feesStartDate, currentPeriodStartDate, currentPeriod, buildingProtectionFee, leaseRentPercentage, chargesFacilityFeeForLiabilityInsurance, facilitiesFeeAmount, turnMoveOutDays, evictionStartDate, leaseNoticeToVacateDays, emergencyEntranceNotice.

Notes for Integrators

  • amenities, officeHours and allowedLeaseTermMonths flatten a one-to-many relationship into a delimited string and are unordered sets — sort client-side if order matters. Every officeHours entry carries its day name for that purpose.
  • lateFeeMethod and securityDepositSimpleInterestRate are kept as a dated history on the property, so both report the value in effect today.
  • quoteExpiration is a duration (SAME_DAY, HOURS_24, HOURS_48, HOURS_72), not a calendar date.
  • siteBuiltDate and lastRenovationDate are free text rather than strict dates, so they may hold a year or a partial date.
  • applicationPortalUrl is only populated while the resident portal is active for the property; availabilityUrl is always present.
  • timezone is an IANA name, or null for the small number of properties with no timezone configured.
  • The subresource follows the usual convention and returns an array holding the single record. Use /propertyConfigurations/{id} for an object.
  • Boolean fields are serialised as the strings "true" and "false" rather than JSON booleans. This applies to every boolean across the API, not just this resource.

Properties Export

New Column on exported_properties

  • propertyClass (varchar) — The property’s class, resolved to its readable name: Conventional, Affordable or Mixed. Null for properties with no class assigned.

Impact on API: The /properties endpoint now includes propertyClass in API responses and data exports, and it can be used in filter and sort.

Documentation & API Updates - August 2, 2026

Messaging API

New Messaging Endpoints

  • Added the Messaging section covering two-way SMS between properties and their customers and prospects.
  • POST /messages — Send an SMS to a customer or prospect. Requires an idempotencyId; retries with the same key return the original message rather than sending a duplicate.
  • GET /messages/{messageId} — Read a single message, including delivery status and attachments.
  • GET /messages — List messages by conversationId, idempotencyId, or messageSid.
  • GET /conversations — List conversations by recipient, by household, or by property.

Notes for Integrators

  • Delivery is asynchronous. A 201 from POST /messages means the message was accepted, not delivered — poll until messageStatus reaches DELIVERED, UNDELIVERED, or FAILED.
  • messageStatus values reported by the carrier are passed through verbatim, so treat the field as an open set of strings.
  • content is limited to 1600 characters, and attachment download URLs expire 15 minutes after they are issued.
  • messages and conversations are separate permission scopes on an API key and are granted independently.

These endpoints are available by request. To explore availability for your integration, please contact our team.

June 2026

Schema & Documentation Updates - June 22, 2026

Certifications Export

New exported_certifications Export Topic Documentation

  • Added dedicated Certifications Export documentation page covering all fields, certification type mappings, program normalization rules, and soft-delete behavior.
  • Added the topic to the Data Exports Integration navigation.

New Columns on exported_certifications

  • unitId (UUID) — ID of the unit from the certification’s tenant event unit record.
  • unitNumber (varchar) — Human-readable unit number resolved from the tenant event; falls back to the Unit table when absent.
  • tenantName (varchar) — Full name of the head of household derived from the latest non-deleted TenantEventPerson record.
  • certificationType (varchar) — Normalized short code: MOVE_IN → MI, annual → AR, interim → IR.
  • dueDate (date) — Recertification due date (recertificationDate).
  • program (varchar) — Normalized program name: HUD, Tax Credit (matches LIHTC/LITHC), Rural Development, or source value.
  • currentStatus (varchar) — Compliance approval status normalized to upper snake case.

Soft-Delete Hardening

  • Added deletedAt IS NULL guards to all joins: TenantEvent, TenantEventUnit, Unit, TenantEventPerson, SetAsideProgram, ComplianceApprovalStatus, RentalAssistanceSource, and secondary subsidy lookups.
  • Household and Property joins are inner joins requiring non-deleted records.

Database View Updates - June 16, 2026

ExportedCertifications View

New Columns for Compliance Reporting:

  • householdIncomeAmount (number) - Total household income as recorded on the certification, in USD
  • marketRentAmount (number) - Market rent amount used for calculations

Impact on API: The /certifications endpoint now includes these fields in API responses and data exports.

May 2026

Documentation & API Updates - May 21, 2026

Screenings API

New previousScreening Field on Applicants

  • Added previousScreening object to each applicant in the GET /screening-requests/{id} response.
  • When an applicant has a prior screening on the same property and provider, previousScreening is populated; otherwise it is null.
  • Object fields: id, requestId, resultId, status, screeningCreatedAt, resultCreatedAt, cancellationReasons.
  • cancellationReasons is always null at this time and reserved for future use.
  • Impact on API: Additive only — no existing fields changed. Consumers that do not read previousScreening are unaffected.
  • Use Case: Enables screening providers to detect prior screenings per applicant and make their own deduplication or re-screening decisions (e.g., mirror prior results if screened within threshold, re-screen fresh if outside threshold, or screen as new if previousScreening is null).

April 2026

Documentation & API Updates - April 2, 2026

ILS Prospect API

New ILS Prospect Creation Endpoint

  • Added OpenAPI documentation for ILS prospect creation endpoint: /external-api/ils-prospects.
  • Added a dedicated API reference section for ILS Prospects, including operation details, request body schema, and response models.
  • Added ILS Prospects overview documentation and linked it in navigation.
  • Updated the ILS Integration menu to include Prospect Creation API reference content.
  • Impact on API: ILS partners now have clear, production URL-based documentation for prospect ingestion.
  • Use Case: Enables ILS vendors to submit prospect leads directly into Fortress using a dedicated API key.

March 2026

Schema Updates - March 19, 2026

Work Orders API

New Priority Value: WARRANTY

  • Added WARRANTY to the priority enum for work orders.
  • Applies to both read models and write payloads (create/update).
  • Impact on API: Work order endpoints now accept and return warranty-prioritized work orders.
  • Use Case: Enables explicit tracking of warranty-related maintenance requests.

February 2026

Documentation Updates - February 20, 2026

New ILS Integration Section

Unit Availability Response Model Documentation

  • Added a comprehensive new section covering ILS integrations, following the MITS 4.1 standard.
  • Includes:
    • Overview of ILS integration and XML response structure
    • Annotated XML skeleton for unit availability responses
    • Field reference table with schema details and enumerations (adapted from MITS Core Data 4.0)
    • Example XML response for integrators
    • Key element descriptions and integration notes
  • Navigation updated to include the new ILS section.
  • Documentation designed to help integrators parse, validate, and utilize unit availability data from Fortress API.

Schema Reference:

  • Field-level details and enumerations are based on the MITS Core Data 4.0 schema (rettc.org).
  • Links to the schema and example files provided for further reference.

December 2025

Documentation Updates - December 5, 2025

API Documentation Enhancements

Availability Indicators

  • Added “Available by Request” badges and notes to restricted endpoints:
    • Move-ins (POST, PUT, DELETE)
    • Move-outs (POST, PUT, DELETE)
    • Document uploads (POST)
    • Property groups (POST, PUT, DELETE)
    • Users (POST, PUT, DELETE)
    • Leases (DELETE - cancellation)
    • Transactions (POST)
    • Scheduled transactions (POST)

Schema Accuracy Updates

  • Prospects: Updated schema to match implementation
    • Made most fields optional (only propertyId required)
    • Added isCorporation field
    • Removed internal bypassDuplicateCheck field
    • Improved validation patterns for phone and email
  • Transactions: Updated schema to reflect optional fields
    • All fields now optional with proper validation
    • Added transactionId to response
    • Clarified householdId/applicationId requirement
  • Scheduled Transactions: Corrected schema definitions
    • Updated type enum to [CHARGE, CREDIT] only
    • Added frequency and documentNumber fields
    • Added pattern validation for date fields
    • Documented SECURITY ledger limitation

Deprecation Notices

  • Marked all report endpoints as deprecated (GET, POST, DELETE)
  • Marked all scheduled report endpoints as deprecated
  • Marked all turn endpoints as deprecated (GET, POST, PUT, DELETE)
  • Added deprecation badges and notes to affected endpoints

Documentation Organization

  • Alphabetically sorted all API paths in OpenAPI specification
  • Alphabetically sorted API reference navigation
  • Created new overview pages:
    • Reversals overview
    • Scheduled Reports overview
    • Turns overview
  • Updated all existing overview pages with complete endpoint listings

Screening API Documentation

  • Added “Onboarding Required” badges to all screening endpoints
  • Created comprehensive integration flow guide with:
    • Step-by-step integration process
    • Code examples for each step
    • Visual Mermaid sequence diagram showing Provider-API-UI interaction
    • Important notes about screening method matching and status handling

Applications API Documentation

  • Created comprehensive integration flow guide for external application providers
  • Added visual Mermaid sequence diagram showing complete application lifecycle
  • Documented 7-step integration process:
    • Create Prospect
    • Qualify & Validate Prospect
    • Create Application From Prospect
    • Assign Unit
    • Application Management (status, applicants, pets, fees)
    • Lease Sync & Document Upload
    • Household Completion Rules
  • Added code examples with curl commands for key operations
  • Included best practices and expectations section covering:
    • ID management and storage requirements
    • Status synchronization guidelines
    • Unit availability validation
    • Data quality standards
    • Reliability and performance optimization
    • Financial transaction handling
    • Document management requirements
  • Updated endpoint reference table with all 14 application-related endpoints

November 2025

Database View Updates - November 26, 2025

ExportedCertifications View

New Columns:

  • contractNumber (string) - Contract number from floor plan affordable program
  • secondarySubsidyType (string) - Name of the secondary subsidy type for the property
  • ownerSignatureDate (timestamp) - Date when the owner signed the certification
  • customerSignatureDate (timestamp) - Date when the head of household signed the certification
  • customerSignatureSuccess (boolean) - Indicates if all lease signers were able to sign

Impact on API: The /certifications endpoint now includes these fields for enhanced affordable housing compliance tracking Use Case: Enables comprehensive HUD certification reporting and signature tracking workflows

ExportedIncomeLimits View

New Column: effectiveDate

  • Type: date
  • Description: Effective date of the income limit for the set-aside program
  • Impact on API: The /incomeLimits endpoint now includes the effective date for each income limit record
  • Use Case: Enables tracking of when income limits became active and historical income limit analysis

Database View Updates - November 25, 2025

ExportedActivities View

Enhanced Activity Types and Status Tracking

Modified Column: type

  • Description: Improved activity type classification with more granular status differentiation
  • New Values:
    • VISITED - Corrected spelling from “VISTED”
    • VISIT_CANCELLED - Specific to visit activities
    • VISIT_NO_SHOW - Specific to visit activities
    • TOUR_CANCELLED - Specific to tour activities
    • TOUR_NO_SHOW - Specific to tour activities
  • Change: Activity type now differentiates between tour and visit cancellations/no-shows

New Column: assignedUserId

  • Type: uuid
  • Description: References the user assigned to the activity
  • Impact on API: The /activities endpoint now includes assignment information
  • Use Case: Enables activity tracking by assigned user and workload reporting

ExportedApplications View

New Columns for Application Form Completion Tracking

New Column: primaryFormCompletedAt

  • Type: timestamp
  • Description: Most recent completion timestamp of the primary form for any applicant on the application
  • Impact on API: The /applications endpoint now tracks when primary application forms were completed
  • Use Case: Enables monitoring of application completion progress and processing timelines

New Column: secondaryFormCompletedAt

  • Type: timestamp
  • Description: Most recent completion timestamp of the secondary form for any applicant on the application
  • Impact on API: The /applications endpoint now tracks when secondary application forms were completed
  • Use Case: Supports detailed application workflow tracking and compliance reporting

Database View Updates - November 17, 2025

ExportedCustomers View

New Column: relationship

  • Type: string (enum)
  • Description: Indicates the relationship of the customer to the head of household
  • Possible Values:
    • PARTNER - Partner/spouse relationship
    • PARENT - Parent of the head of household
    • ADULT_CHILD - Adult child of the head of household
    • ROOMMATE - Roommate relationship
    • CHILD - Minor child
    • GUARANTOR - Lease guarantor
    • OTHER - Other relationships
    • null - For head of household (no relationship to self)
  • Impact on API: The /customers endpoint now includes this field in API responses and data exports
  • Use Case: Enables filtering and reporting based on household member relationships

Schema Updates - November 14, 2025

ScreeningRequest Schema

New Field: socialSecurityNumber

  • Type: string
  • Description: Social Security Number for applicant employment information (secured and encrypted)
  • Location: Within the employmentInformation object in screening requests
  • Impact on API: The screening request payload now accepts SSN as part of employment verification data
  • Security: All SSN data is encrypted in transit and at rest
  • Use Case: Enables more comprehensive background screening and employment verification

Database View Updates - November 13, 2025

ExportedUserProperties View

New View Created

  • Description: Exposes user-to-property associations for access control and permission management
  • Columns:
    • id (uuid) - Unique identifier for the user property association
    • userId (uuid) - Reference to the user
    • propertyId (uuid) - Reference to the property
    • organizationId (uuid) - Reference to the organization (joined from Property)
    • createdAt (timestamp) - When the association was created
    • updatedAt (timestamp) - When the association was last updated
  • Impact on API: New /userProperties endpoint available for querying user property access
  • Use Case: Enables tracking which users have access to which properties and supports multi-property user management

Database View Updates - November 12, 2025

ExportedLeases View

New Column: moveOutId

  • Type: uuid
  • Description: References the most recent Notice to Vacate (move out) ID associated with the lease
  • Impact on API: The /leases endpoint now includes this field in API responses and data exports
  • Use Case: Enables direct tracking of move out notices and lease termination workflows

ExportedScheduledTransactions View

New Column: description

  • Type: string
  • Description: Human-readable description of the transaction code from the master transaction code table
  • Impact on API: The /scheduledTransactions endpoint now includes this field in API responses and data exports
  • Use Case: Provides clearer context for scheduled charges without requiring separate lookups

Enhanced Lease Renewal Logic

  • Description: Updated view logic to properly track scheduled transactions through lease renewals
  • Impact on API: Scheduled transactions now correctly reference the most recent active lease when renewals exist, and only include transactions for moved-in leases
  • Use Case: Ensures scheduled transactions remain accurate and accessible through the lease lifecycle

Database View Updates - November 7, 2025

ExportedCustomers View

New Column: relationship

  • Type: string (enum)
  • Description: Indicates the relationship of the customer to the head of household
  • Possible Values:
    • PARTNER - Partner/spouse relationship
    • PARENT - Parent of the head of household
    • ADULT_CHILD - Adult child of the head of household
    • ROOMMATE - Roommate relationship
    • CHILD - Minor child
    • GUARANTOR - Lease guarantor
    • OTHER - Other relationships
    • null - For head of household (no relationship to self)
  • Impact on API: The /customers endpoint now includes this field in API responses and data exports
  • Use Case: Enables filtering and reporting based on household member relationships

ExportedUnits View

New Column: reportConfigurationValue

  • Type: string
  • Description: Contains the report configuration value for each unit based on property settings
  • Possible Values:
    • Quoting Rent
    • Financial Market Rent
    • Market Rent
  • Impact on API: The /units endpoint now includes this field in API responses and data exports
  • Use Case: Enables property-specific rent reporting configurations and filtering by rent type

October 2025

Database View Updates - October 31, 2025

ExportedLeases View

New Column: documentId

  • Type: uuid
  • Description: References the document ID associated with each lease
  • Impact on API: The /leases endpoint now includes this field in API responses and data exports
  • Use Case: Enables direct document tracking and retrieval for lease records

Database View Updates - October 24, 2025

ExportedCustomers View

Enhanced Household Relationships

New Column: headOfHousehold

  • Type: boolean
  • Description: Indicates whether the customer is the head of household
  • Impact on API: The /customers endpoint now includes this field in API responses and data exports
  • Use Case: Simplifies identification of primary household members

Modified Column: householdId

  • Description: Now properly associates customers with households through the applicant relationship
  • Impact on API: The /customers endpoint now returns household associations for all household members in API responses and data exports (previously only available for primary household members)
  • Change: This field now populates for all household members, not just the primary customer

Breaking Changes

ExportedCustomers View - October 24, 2025

⚠️ Potential Breaking Change

The householdId field has been updated to use the applicant relationship instead of direct household association. This may affect:

  • Queries filtering by householdId for non-primary household members
  • Data exports relying on the previous household association logic
  • Reports that aggregate customer data by household

Migration: Review any queries or integrations using the householdId field from the customers endpoint to ensure they still return expected results.

Schema Reference

All database views are located in /db/views/ and are synchronized to the API through the data export layer. Changes to these views are automatically reflected in the corresponding API endpoints:

  • ExportedUnits.sql → /units endpoint
  • ExportedLeases.sql → /leases endpoint
  • ExportedCustomers.sql → /customers endpoint
  • ExportedScheduledTransactions.sql → /scheduledTransactions endpoint
  • ExportedUserProperties.sql → /userProperties endpoint

Support

For questions about these changes or to report issues: