Applications Overview

The Applications API provides endpoints for managing rental applications throughout the application process.

Key Concepts

Application Status

Applications can be in various states:

• APPROVED - Application has been approved
• IN_PROCESS - Application is being reviewed
• DENIED - Application has been denied
• WAITLIST - Application is on waitlist
• CANCELED - Application was canceled
• ABANDONED - Application was abandoned

Integration Flow

The Fortress application lifecycle follows a structured flow that ensures proper data management and system integration. Below is the required sequence for external application providers:

Step 1: Create a Prospect

All applications must begin with a prospect record. A prospect represents a lead entering the system.

Endpoint: POST /prospects

$
curl -X POST https://api.fortress.build/prospects \
>
  -H "Authorization: Bearer YOUR_API_KEY" \
>
  -H "Content-Type: application/json" \
>
  -d '{
>
    "propertyId": "uuid",
>
    "firstName": "John",
>
    "lastName": "Doe",
>
    "email": "john.doe@example.com",
>
    "phone": "555-123-4567"
>
  }'

Important: Store the returned prospectId - it will be referenced throughout the lifecycle.

Step 2: Prospect Qualification & Validation

Your system is responsible for qualification logic if performed externally. Once validated, you may convert the prospect into an applicant by creating an application.

Step 3: Create Application From Prospect

An application can only be created from an existing prospect.

Endpoint: POST /applications

Required Input:

• prospectId - The prospect ID from Step 1
• unitId - The unit being applied for
• Applicant details

$
curl -X POST https://api.fortress.build/applications \
>
  -H "Authorization: Bearer YOUR_API_KEY" \
>
  -H "Content-Type: application/json" \
>
  -d '{
>
    "prospectId": "uuid",
>
    "unitId": "uuid",
>
    "applicants": [...]
>
  }'

Step 4: Assign Unit

A unit must be assigned at creation time. Unit assignment is mandatory before an application can move to approval.

If the unit changes later, you must use the corresponding update endpoint (if allowed).

Step 5: Application Management

Status Updates

The application provider is responsible for reflecting real-time status changes.

Endpoint: PUT /applications/{id}/status

Common statuses:

• In Progress
• Approved
• Denied
• Cancelled

Status updates must remain synchronized with your system.

Managing Applicants

If the number of applicants changes during the application process, use these endpoints:

Managing Pets

Pets are part of the household makeup and must be synced during the application lifecycle.

Fee Collection & Payments (Optional)

If the Application Provider handles fee collection (application fees, holding deposits, etc.):

Endpoint: POST /transactions

Requirements:

• Each transaction requires a valid transaction code
• Transaction codes are defined per organization/property by Fortress
• You must confirm transaction codes before development begins

$
curl -X POST https://api.fortress.build/transactions \
>
  -H "Authorization: Bearer YOUR_API_KEY" \
>
  -H "Content-Type: application/json" \
>
  -d '{
>
    "applicationId": "uuid",
>
    "amount": 50.00,
>
    "transactionCode": "APP_FEE",
>
    "ledger": "RENT"
>
  }'

Step 6: Lease Sync & Document Upload

If your system handles leasing outside of Fortress, upon application approval and lease execution:

You must send a copy of the signed lease

Endpoint: POST /households/{id}/documents

This ensures Fortress maintains a full household record.

Step 7: Household Completion Rules

Once the lease is completed, the household is locked. No further modifications are allowed to:

• Customers
• Pets
• Household structure
• Lease metadata

Best Practices & Expectations

To ensure successful integration with the Fortress application lifecycle, follow these best practices:

ID Management

• Always store all IDs returned from Fortress (prospect, application, customer, unit, household)
• Reference these IDs throughout the application lifecycle
• Do not assume IDs can be regenerated or retrieved without proper storage

Status Synchronization

• Keep your application statuses aligned with Fortress’s allowed status model
• Ensure real-time synchronization of status changes
• Validate status transitions are permitted before updating

Unit Assignment

• Validate unit availability before assigning
• Ensure the unit is eligible for the application
• Respect unit-level availability rules unless bypass is enabled

Data Quality

• Do not send incomplete or placeholder applicants
• Ensure all required fields are populated with accurate data
• Validate data before submission to avoid processing errors

Reliability & Performance

• Use idempotency keys for safe retry logic (if supported in your contract)
• Implement proper error handling and retry mechanisms
• Avoid unnecessary calls to prevent throttling and ensure optimal performance

Financial Transactions

• Confirm transaction codes before implementing fee collection
• Verify codes are valid for your organization/property
• Test transaction processing in a non-production environment first

Document Management

• Ensure lease documents are final and complete before uploading
• Upload only signed, executed lease agreements
• Verify document format and content before submission

Available Endpoints