Work with PropOS properties and applications from your own systems.

The PropOS Public API is a pre-GA, server-to-server API for property-manager workspaces. Use it to manage workspace-owned properties and read the applications for those properties without depending on private web-app routes.

Pre-GA contract#

• All supported operations are under /api/v1/**.
• The current contract version is 0.1.0-pre-ga.
• Pre-GA responses and operations may change before general availability. We will publish migration guidance for breaking changes.
• The supported public surface is limited to the property and application operations shown in the API reference. Web-app identity and API-key lifecycle routes are intentionally excluded from the public OpenAPI document.

Base URL#

Public API requests are served from the app subdomain:

• https://app.propos.rent/api/v1

Every response includes X-API-Version: v1, and every response envelope includes meta.apiVersion = "v1".

Create a workspace API key#

In PropOS, switch to the property-manager workspace that will own the integration, then open Workspace Profile → API Keys. Workspace owners and admins with API-key access can create, rename, rotate, finalise, cancel, and revoke keys.

Choose at least one scope when creating a key:

• properties:read:own
• properties:write:own
• applications:read:own

The secret is displayed once. Store it in a secret manager; do not put it in source control, logs, browser storage, query strings, or URLs. A workspace can have at most 10 active keys.

Authenticate#

Send the workspace API key with either supported header:

curl --request GET \
  --url "https://app.propos.rent/api/v1/properties" \
  --header "Authorization: Bearer $PROPOS_API_KEY"

curl --request GET \
  --url "https://app.propos.rent/api/v1/applications" \
  --header "X-API-Key: $PROPOS_API_KEY"

The key is a service principal for exactly one property-manager workspace. Its scopes and workspace ownership are both enforced. A key cannot read or modify resources merely because its creator can access them in another workspace.

Rotate and revoke keys#

Rotation creates a replacement key and starts an explicit overlap in which both keys remain active until an admin finalises or cancels it:

1. Start rotation in Workspace Profile → API Keys and copy the replacement secret.
2. Update the integration and confirm requests succeed with the replacement.
3. Finalise rotation to revoke the original, or cancel rotation to revoke the replacement.

An original key with an unfinished rotation cannot be revoked directly. Revoke any key immediately if compromise is suspected. Deleting a property-manager workspace or changing it to an ineligible workspace type revokes its keys and cancels unfinished rotations.

Supported operations#

Properties#

• GET /api/v1/properties — properties:read:own
• GET /api/v1/properties/:id — properties:read:own
• POST /api/v1/properties — properties:write:own
• PUT /api/v1/properties/:id — properties:write:own
• DELETE /api/v1/properties/:id — properties:write:own

Property responses always include managerWorkspaceId. The ID identifies the workspace that owns the property and must match the API key's workspace.

Applications#

• GET /api/v1/applications — applications:read:own
• GET /api/v1/applications/:id — applications:read:own
• GET /api/v1/applications/:id/applicants — applications:read:own

Application responses include managerWorkspaceId. Applicant workspace ownership is private and is not returned by the public API.

Create a property#

curl --request POST \
  --url "https://app.propos.rent/api/v1/properties" \
  --header "Authorization: Bearer $PROPOS_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "title": "Sea Point apartment",
    "streetAddress": "12 Example Road",
    "monthlyRent": 18000
  }'

The server assigns the property to the API key's workspace. A client cannot use the request body to select another manager workspace.

Response envelopes#

Successful responses use a data envelope:

{
  "data": {},
  "meta": {
    "requestId": "request-id",
    "timestamp": "2026-07-17T00:00:00.000Z",
    "apiVersion": "v1"
  }
}

Errors use an error envelope:

{
  "error": {
    "code": "FORBIDDEN",
    "message": "Access denied",
    "details": {}
  },
  "meta": {
    "requestId": "request-id",
    "timestamp": "2026-07-17T00:00:00.000Z",
    "apiVersion": "v1"
  }
}

Common codes are UNAUTHORIZED (401), FORBIDDEN (403), NOT_FOUND (404), RATE_LIMITED (429), and INTERNAL_SERVER_ERROR (500). Authorisation failures may use 404 to avoid exposing whether a resource exists.

Pagination and rate limits#

List operations accept page and limit. Paginated responses include meta.pagination with page, limit, total, and totalPages.

Each key is limited to 1,000 requests per hour. Responses expose X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset when available. A rate-limited request returns 429 and may include Retry-After.

Privacy#

Application responses may contain applicant contact details, submitted evidence, and identity numbers. Request only what the integration needs, restrict downstream access, and follow the Privacy Policy. The API removes internal review notes, signature data, payment/card data, and request audit fields at the public boundary.

Use the API reference for the current machine-readable schemas and examples.