RentEngine Public API (1.1.1)

Integrate your systems anywhere with RentEngine.

Authorization

This API uses JWT Bearer token authentication. Follow these steps to obtain and use your API tokens:

Obtaining API Tokens

Log in to your RentEngine developer portal
In the top corner, click the "Create New API Key" button
Provide a name for your token (e.g., "Integration Name")
Click Create
Copy the token to your clipboard and save it securely as it will not be displayed again

Important Security Notice: Your token will only be displayed ONCE at creation time. Make sure to copy it and store it securely. For security reasons, we cannot display the token again after this point.

Using API Tokens

Include your token in all API requests as a Bearer token in the Authorization header:

Authorization: Bearer your_token_here

Token Security Best Practices

Store tokens securely in environment variables or a secure vault
Never hardcode tokens in your application code
Do not share tokens in public repositories or client-side code
Use separate tokens for different integrations or environments

Token Permissions

Each token generated by a user will have the full permissions of the user that created it across all accounts associated with that user. Actions will be logged in the name of that user & token.

Invalidating Tokens

Tokens will not expire. (Well not for 100 years at least). If a token is compromised or no longer needed:

Log in to your RentEngine developer portal
Find the token you wish to invalidate in the table in the API Keys section
Click the "Revoke Token" icon that looks like a trash can

Once revoked, a token cannot be restored. You'll need to create a new token if needed.

Pagination

Most list endpoints in the RentEngine API support pagination to efficiently handle large datasets. Paginated endpoints accept the same query parameters, but there are two response formats in use. Check the endpoint's response schema to determine which format it returns. A few endpoints return a fixed, bounded result set instead of paging (e.g. GET /market-tool/comps returns up to 200 most recently active comparables) — these do not accept pagination parameters.

Pagination Parameters (all list endpoints)

limit - Controls how many items to return per page (default: 50, max: 100)
page_number - Specifies which page to retrieve (0-indexed, default: 0)

Example request with pagination:

GET /api/public/v1/lockboxes?limit=25&page_number=1

This would return the second page of results with 25 items per page.

Response Format A — Bare Array (legacy)

Most list endpoints return a bare JSON array containing only the requested page of items. The response does not include the total count or an explicit end-of-data marker.

Endpoints using this format include:

/lockboxes
/lockbox_events
/lockbox_installations
/units
/prospects
/subteams
/prescreening_templates
/rental_applications

Example response:

[
  { "id": "...", "...": "..." },
  { "id": "...", "...": "..." }
]

To iterate, increment page_number until the response array is shorter than the requested limit — that indicates the last page.

Response Format B — Envelope with Page Metadata

Newer list endpoints wrap the data in an envelope that includes explicit pagination metadata, so you don't have to infer the end of the dataset from the array length.

Endpoints using this format include:

/rental_application_groups

Example response:

{
  "data": [
    { "id": "...", "...": "..." },
    { "id": "...", "...": "..." }
  ],
  "page": {
    "limit": 50,
    "page_number": 0,
    "has_more": true,
    "next_page_number": 1
  }
}

Fields in the page object:

limit - The limit value used for this response (echoes the request)
page_number - The 0-indexed page returned (echoes the request)
has_more - true if additional pages are available, false on the final page
next_page_number - The page number to request next, or null when has_more is false

To iterate, follow next_page_number until it is null (or has_more is false).

Performance Considerations

Use appropriate limit values based on your needs. Smaller values reduce payload size but require more API calls, which can slow down performance and be subject to rate limits.
When filtering data, apply filters in the query parameters first to reduce the total number of items that need to be fetched.

Rate Limiting

To ensure fair usage and protect our infrastructure, all API endpoints are rate limited. Rate limits are applied per user (based on your API token).

Default Rate Limits

Tier	Requests	Window
Standard	30	5 seconds
Strict	10	5 seconds
Market Tool	40	24 hours

Most endpoints use the "Standard" tier. Endpoints that return PII or stream binary artifacts — GET /rental_applications/{id} and GET /rental_applications/{id}/documents/{documentId} — use the "Strict" tier (2 req/s).

The market comps endpoint — GET /market-tool/comps — uses the "Market Tool" tier (40 requests per 24 hours) and is metered: each successful call incurs a $0.50 charge to your account. The strict daily limit and per-call charge exist to prevent abuse of this data-intensive endpoint.

Rate Limit Headers

All API responses include headers to help you track your rate limit status:

Header	Description
`X-RateLimit-Limit`	Maximum requests allowed in the current window
`X-RateLimit-Remaining`	Number of requests remaining in the current window
`X-RateLimit-Reset`	Unix timestamp (milliseconds) when the rate limit resets

Handling Rate Limits

When you exceed the rate limit, you'll receive a 429 Too Many Requests response with a Retry-After header indicating how many seconds to wait before retrying.

{
  "error": "Too Many Requests",
  "message": "Rate limit exceeded. Please try again later.",
  "retryAfter": 4
}

Best Practices

Monitor the X-RateLimit-Remaining header to avoid hitting limits
Implement exponential backoff when retrying after a 429 response
Cache responses when possible to reduce API calls
Use webhooks for real-time updates instead of polling

Webhooks

RentEngine provides webhooks to notify your systems about events in real-time. This allows you to build integrations that respond immediately to changes in your RentEngine data.

Setting Up Webhooks

Webhooks can be configured through the RentEngine developer portal. You'll need to specify:

The target URL where webhook events should be sent
The data you want to monitor (e.g., lockboxes, units, lockbox_events)
The event types you want to receive (INSERT, UPDATE, DELETE)
An optional API key that will be included in webhook requests to your endpoint

Webhook Payload Structure

Webhook payloads follow this general structure:

{
  "type": "INSERT|UPDATE|DELETE",
  "table": "table_name",
  "record": { /* The current state of the record (null for DELETE) */ },
  "old_record": { /* The previous state of the record (null for INSERT) */ }
}

The specific fields in record and old_record will depend on the table that triggered the event.

Event Types

INSERT: Sent when a new record is created
UPDATE: Sent when an existing record is modified
DELETE: Sent when a record is deleted

Security Considerations

Webhook endpoints should be HTTPS to ensure secure transmission of data
Validate the API key included in the webhook request to ensure it's coming from RentEngine
Implement idempotency in your webhook handlers to prevent duplicate processing

Webhook Delivery

RentEngine uses a reliable delivery system (QStash) to ensure webhooks are delivered even during temporary outages. If your endpoint is unavailable, we'll retry delivery with exponential backoff.

Download OpenAPI description

openapi.json

openapi.yaml

Overview

URL

https://rentengine.io

E-mail

eng@rentengine.io

License

Proprietary

Languages

Servers