Leasey API Documentation

Which API do you need?

1Getting Started

Credentials and where to get them

Which API do you use?

2Authentication & API Keys

API keys (recommended)

Send only the key, in the Authorization header. No company_id and no company password: the key already says which company you are.

GET /reports/syndication
Authorization: Bearer lsy_live_<40 characters>

PUT /properties/39e00f97-c0a0-48f0-9ebb-38f1a50e3f5b
Authorization: Bearer lsy_live_<40 characters>
Content-Type: application/json

{ "property": { "marketplaces": [ { "name": "kijiji", "enabled": true } ] } }

• Every endpoint accepts an API key, with the same requests and responses. If a request also carries company_id or password, they are ignored: a key only acts on its own company.
• Access level. A Full access key can do everything. A Read only key can only GET (reports, leads, showings, catalogs, applications, screening, leases, documents); any write answers 403 with code: api_key_read_only. Use read-only keys for dashboards and reporting tools.
• Create and revoke keys in the Leasey dashboard: Profile → Developers. Only company administrators see that section, the full key is shown once (with a copy button), and every administrator receives an email when a key is created (in the company's language). Revoking sends no email and takes effect immediately on every route.
• Expiration (optional). By default a key never expires: it works until it is revoked. When you create it you can choose a date instead (30 days, 90 days, 1 year or any date); after that moment every request with the key answers 401 with code: api_key_expired ("This API key has expired. Create a new one in Leasey: Profile > Developers."). The date cannot be changed later: before it arrives, create the replacement and revoke the old key. Each key in the list carries status (active, expired or revoked) and expires_soon (true in the last 7 days, while the key still works).
• Limited to some resources (optional). A key can also be limited to the resources it needs, for example a voice agent that only books showings: "resources": ["showings"] when you create it with POST /api-keys. Any other route answers 403 with code: api_key_resource_not_allowed. The resources are properties (units and marketplaces), leads (/properties/leads), showings, reports, webhooks, applications, screening, leases, documents and api_keys (list, create and revoke keys). Access level and resources combine: a read-only key limited to applications can only read applications. A key without the list, like every key created before 3.15, can use every resource. A limited key can only create keys within its own resources, and needs api_keys to manage keys at all.
• Rotate without downtime from your own system, using a full-access key:

Rotation: create the new key, deploy it, check that last_used_at of the old key stops moving, revoke the old key.

• Errors. Unknown key 401 invalid_api_key; revoked 401 api_key_revoked; expired 401 api_key_expired; read-only key on a write 403 api_key_read_only; key limited to other resources 403 api_key_resource_not_allowed.

Legacy credentials (token + company password)

Existing integrations keep working unchanged, and both methods can be used at the same time while you migrate. Leasey will announce a retirement date with notice; new integrations should use API keys.

¹ GET /properties/{id}/marketplaces, GET /properties/leads and GET /webhooks take the password only as the password query parameter (they do not read the header). The /reports/* endpoints use the X-Company-Password header.

company_id travels as a query parameter on GET and as a JSON body field on POST/PUT.

GET /reports/syndication?company_id=128
Authorization: Bearer <YOUR_API_TOKEN>
X-Company-Password: <YOUR_COMPANY_PASSWORD>

3Environments & Sandbox

Each environment is a separate system with its own API token, company_id, company password and keys (lsy_test_… / lsy_org_test_… only work in the sandbox, lsy_live_… / lsy_org_live_… only in production). Routes, headers and bodies are identical.

All paths in this documentation are relative to the base URL, which already includes the version: GET /reports/showings means https://api.leasey.ai/v1/reports/showings. Without /v1 the domain answers a bare 403 Forbidden.

Previous base URLs. Until November 2026 the base URLs were https://uvciw58bnh.execute-api.ca-central-1.amazonaws.com/production and https://hs52apwqwh.execute-api.ca-central-1.amazonaws.com/staging. They keep working with exactly the same routes, credentials and responses, so existing integrations need no change; new integrations should use the URLs above.

What the sandbox guarantees

• No real charges. Billing runs against Stripe in test mode. To try paid marketplaces end to end, add a Stripe test card (4242 4242 4242 4242, any future expiry, any CVC) under Settings → Billing in the sandbox dashboard; without a card, paid activations are refused with payment_method_required exactly as in production.
• No publishing to live marketplaces. The feeds marketplaces read are production's, so sandbox listings never reach them. The one exception is Craigslist, which Leasey pushes to directly: don't enable it in the sandbox.
• Same code as production. Same API version.
• Your own data only. The sandbox account starts empty and is isolated from every other account.
• In the sandbox the daily billing job is off: charges stay pending and are never invoiced.

Health check. GET /health needs no credentials, in both environments (https://api.leasey.ai/v1/health and https://sandbox.api.leasey.ai/v1/health). It answers 200 with {"status": "ok", "checks": {"database": "ok"}, "checked_at": "2026-11-06T15:00:00Z"} when the API can serve requests, and 503 with code: service_unavailable when it cannot reach its database. The response is never cached, so you can point your own monitoring at it. Leasey checks both environments the same way every 5 minutes; the results and the incident history are public at status.leasey.ai.

Sandbox credentials come with the onboarding email, together with a dashboard user for the sandbox. Sandbox keys are created in the sandbox dashboard's Developers tab.

4Conventions, Pagination & Limits

JSON everywhere. Requests with a body send Content-Type: application/json; every response is JSON with success: true on success or an error + message pair on failure.

Dates. Send ISO-8601: YYYY-MM-DD for dates, YYYY-MM-DDTHH:MM:SS where a time matters (use 00:00:00 / 23:59:59 for start / end of day). Report rows return "YYYY-MM-DD" or "YYYY-MM-DD HH:MM:SS" strings, except Date_Available and Updated_At in /reports/properties, which are ISO 8601 with a T (see "Column reference" in section 8). The leasing routes (section G5) return ISO 8601 timestamps in UTC with a Z, and YYYY-MM-DD for lease dates.

Report date defaults. If you omit start_date on /reports/showings and /reports/leads, the report starts on January 1 of the current year (not "all history"). /reports/properties is not date-filtered. /reports/billing filters on when the charge was created; /reports/syndication on billing periods. To pull only what changed since your last sync, use updated_since (see Reports API).

Data types in responses

Older text fields and their _number twins (since 3.18). A few payloads from before 3.14 send some values as text: application_id, person_id and rent_amount in /properties/leads and lead.received; price, bedrooms and bathrooms in /showings/lookup; slot_id in the reschedule response; Parking_Stalls in /reports/showings. They stay as they are, so existing integrations keep working, and each one now has a twin with the same value as a number: application_id_number, person_id_number, rent_amount_number, price_number, bedrooms_number, bathrooms_number, slot_id_number, Parking_Stalls_Number. Use the twins; the text fields are deprecated (marked in openapi.yaml) and stay in v1 (see "Versioning and deprecation" in section 4). A twin is null when the stored text is not a number.

Pagination

/reports/properties, /reports/leads, /reports/showings and /reports/billing: add page and page_size (max 5000). /reports/syndication is a snapshot with one row per unit and marketplace and is not paginated. The leasing lists (section G5) are always paginated: page_size defaults to 100, with a max of 500. Without them the full report is returned, subject to a 6 MB cap — beyond it you get 413 with a suggested page size instead of a silent failure. Paginated bodies carry:

"count": 1000, "total_rows": 5005,
"pagination": { "page": 1, "page_size": 1000, "total_pages": 6, "has_more": true }

/properties/leads uses limit (max 500).

Stable sort order

Every report has a fixed order, so paging never skips or repeats a row while the data does not change:

Operational limits

Rate limiting

There is no usage quota. A protective throttle stops abnormal bursts, far above the volume of a normal integration. When it triggers, the API answers 429 Too Many Requests with a Retry-After header (seconds) and the standard error body. Wait the number of seconds in Retry-After and retry; if it happens again, back off exponentially (1 s, 2 s, 4 s… up to 60 s). Batching marketplace toggles into one PUT, polling leads every 5–15 minutes (or using webhooks) and paginating large reports keeps you far from the throttle. The throttle is active in both environments (50 requests/s sustained, bursts of 100).

HTTP/1.1 429 Too Many Requests
Retry-After: 1
X-Request-Id: b72179d9-745e-4333-b541-a35b6e89e332

{ "error": "Too Many Requests", "code": "rate_limited",
  "message": "Too many requests. Wait the number of seconds in the Retry-After header and retry.",
  "request_id": "b72179d9-745e-4333-b541-a35b6e89e332" }

Versioning and deprecation

v1 is the major version of the API and is part of the base URL. Within v1 every change is additive — new endpoints, new optional parameters, new response fields and report columns, new values of an enumerated field, new error codes — and existing ones keep their name, type and meaning (the message text of an error may be reworded; program against code). Every change is listed with its date in the Changelog at the end of this page; the release number (currently 3.18) is the one in the header and in openapi.yaml. A change that would break existing integrations — renaming or removing a field, changing a type or the meaning of a value — ships as v2 on the same domains, announced in advance, and v1 keeps running for at least 12 months after that announcement. The legacy credentials (token + company password) keep working; Leasey will announce a retirement date with the same notice.

5Errors & Troubleshooting

Errors are always JSON, with the HTTP status that matches the problem:

{
  "error": "Unauthorized",
  "code": "invalid_api_key",
  "message": "Invalid API key.",
  "request_id": "0926a21a-0073-4d9b-8c73-a2a85b22202e"
}

Some errors add context fields: details (422), missing_fields and missing_questions (POST /showings), is_waitlist (wrong booking mode), suggested_page_size (413), property_id (409 on a duplicate unit name).

Errors answered by the gateway itself (unknown route, throttling, timeout) use the same JSON format and carry the same code and request_id.

Error codes. The complete table is in the Error Reference.

A 422 on create/update includes details with one message per invalid field. Real example (three problems in one request — all reported at once):

{
  "error": "Unprocessable Entity",
  "message": "Validation failed. See 'details' for field-level errors.",
  "details": [
    "\"address\" is required.",
    "\"unit_type\" invalid: \"castle\". Valid values: ['apartment', 'house', 'townhouse', 'duplex/triplex', 'basement suite', 'other', 'room only']",
    "\"marketplaces[0].name\" = \"kijijji\" is not a valid marketplace. Valid values: ['apartmentsPremium', 'apartmentsStandard', 'craigslist', 'facebook', 'immediateRent', 'kijiji', 'lespac', 'listanza', 'livRent', 'lq', 'realtor', 'rentFaster', 'rentPanda', 'rentSeeker', 'rentalBeast', 'rentalSource', 'rew', 'viewit', 'zillow', 'zillowMulti', 'zumperPremium', 'zumperStandard']"
  ]
}

Nothing is created on a 422 — fix every entry in details and resend. The list of valid marketplace names in this example predates streetEasy: the API now accepts 23 names (see the Marketplace Directory in the Syndication API tab). Marketplace entries inside an otherwise-valid request fail individually (status: "error" in the response array) without aborting the rest. An error mentioning "Invalid key=value pair in Authorization header" (or 403 with code: route_not_found) means the URL/route is wrong, not the credentials.

Troubleshooting by symptom

6Your First Request (5 minutes)

cURL — API key (one header, no company_id, no password)

curl "https://api.leasey.ai/v1/reports/showings?start_date=2026-08-01&end_date=2026-08-31" \
  -H "Authorization: Bearer lsy_live_YOUR_KEY"

You should get 200 with {"success": true, "report_type": "showings", "count": …, "data": [...]}. An empty data array is still success — it means no showings in that range.

cURL — legacy credentials (second option)

curl -X GET \
  "https://api.leasey.ai/v1/reports/showings?company_id=YOUR_COMPANY_ID&start_date=2026-08-01&end_date=2026-08-31" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "X-Company-Password: YOUR_COMPANY_PASSWORD"

Python — API key

import requests

BASE = "https://api.leasey.ai/v1"
HEADERS = {"Authorization": "Bearer lsy_live_YOUR_KEY"}

# Read
r = requests.get(f"{BASE}/reports/showings", headers=HEADERS,
                 params={"start_date": "2026-08-01"})
r.raise_for_status()
print(r.json()["count"], "showings")

# Write
r = requests.post(f"{BASE}/properties", headers=HEADERS,
                  json={"property": {"name": "Unit 2B", "address": "456 Oak Ave",
                                     "city": "Toronto", "province_state": "ON",
                                     "country": "Canada", "rent_amount": "2100"}})
print(r.status_code, r.json().get("property_id"))

Python — legacy credentials

HEADERS = {"Authorization": "Bearer YOUR_API_TOKEN",
           "X-Company-Password": "YOUR_COMPANY_PASSWORD"}

# Read: credentials in headers, company_id in the query string
r = requests.get(f"{BASE}/reports/showings", headers=HEADERS,
                 params={"company_id": YOUR_COMPANY_ID, "start_date": "2026-08-01"})

# Write: company_id + password inside the JSON body
r = requests.post(f"{BASE}/properties",
                  headers={"Authorization": "Bearer YOUR_API_TOKEN"},
                  json={"company_id": YOUR_COMPANY_ID, "password": "YOUR_COMPANY_PASSWORD",
                        "property": {"name": "Unit 2B", "address": "456 Oak Ave",
                                     "city": "Toronto", "province_state": "ON",
                                     "country": "Canada", "rent_amount": "2100"}})

Postman in four steps

1. Environments → New: add base_url (the production URL above) and api_key (or, for the legacy method, api_token, company_id, company_password).
2. New request GET {{base_url}}/reports/showings → Headers: Authorization = Bearer {{api_key}} → Send.
3. New request POST {{base_url}}/properties → Headers: Authorization, Content-Type: application/json → Body (raw JSON): {"property": {…}} → Send.
4. Or skip steps 2–3: File → Import the openapi.yaml and every endpoint appears pre-built — just fill the environment.

7Retries and Idempotency-Key

Every write can be retried safely. To make a retry explicit, send an Idempotency-Key header with a value you generate for that operation (a UUID works; up to 255 characters: letters, digits, ., _, : and -). It is accepted on POST /properties, PUT /properties/{property_id}, POST /showings, PUT /showings/{slot_id}/reschedule, POST /showings/{slot_id}/cancel and POST /showings/{slot_id}/confirm (and on the same routes under /org/companies/{id}/…).

POST /properties
Authorization: Bearer lsy_live_…
Content-Type: application/json
Idempotency-Key: 6f1c2a1e-6c39-4c47-9d2e-1b8f4f0a9e21

{ "property": { "name": "Unit 2B", "address": "456 Oak Ave", "city": "Toronto",
                "province_state": "ON", "country": "Canada", "rent_amount": 2100 } }

• Keys belong to your credentials: another partner's key never collides with yours.
• 5xx responses are not stored, so you can retry them with the same key.
• A malformed header answers 400 invalid_idempotency_key.
• Without the header the writes are still protected by their natural rules: POST /properties answers 409 with the existing property_id when the name already exists; re-sending the same marketplace state answers no_change and is never billed twice; POST /showings for the same person and event updates their showing instead of creating another; reschedule, cancel and confirm always land on the same final state.

8Reports API

The five reports below are common to both APIs: same endpoints, same envelope, same pagination.

Which report for what

All five share the envelope (success, report_type, company_id, count, total_rows, data, optional pagination) and the same authentication as every other endpoint (an API key, or the legacy token + X-Company-Password). Possible values of every enumerated field are listed in the Field Values (Enums) reference — use them for filters and status badges.

Date filters

Both accept a date (2026-11-03) or a date-time (2026-11-03T14:00:00). A bare date means midnight at the start of that day: end_date=2026-11-03 stops at 00:00 on November 3, so send 2026-11-04 or 2026-11-03T23:59:59 to include the whole day. A change of stage or status does not move these dates; to pick up changes, use updated_since.

Incremental sync: updated_since

Returns only the rows that changed since that moment, and every row carries Updated_At (UTC):

GET /reports/syndication
Authorization: Bearer lsy_live_…

GET /reports/syndication?company_id=128
Authorization: Bearer <YOUR_API_TOKEN>
X-Company-Password: <YOUR_COMPANY_PASSWORD>

Optional start_date / end_date filter the billing periods included.

Response 200 OK — real example, truncated

{
  "success": true,
  "report_type": "syndication",
  "company_id": 128,
  "count": 32,
  "summary": {
    "properties_with_syndication": 8,
    "active_listings": 23,
    "total_billed": [ { "currency": "CAD", "amount": 142.50 } ],
    "by_marketplace": [
      { "marketplace": "viewit",         "active_listings": 0, "total_billed": 66.00 },
      { "marketplace": "kijiji",         "active_listings": 0, "total_billed": 30.00 },
      { "marketplace": "livRent",        "active_listings": 0, "total_billed": 24.90 },
      { "marketplace": "zumperStandard", "active_listings": 0, "total_billed": 12.60 }
    ]
  },
  "data": [
    {
      "Property_ID": "11eb3469-863d-477f-849c-19132b564e50",
      "Property_Name": "Sofia Residences Unit 701",
      "Marketplace": "zillow",
      "Active": true,
      "Published_Since": "2026-07-30 20:54:22",
      "Last_Action": "published",
      "Last_Action_Date": "2026-07-30 20:54:22",
      "Days_Billed": 0,
      "Total_Billed": 0.0,
      "Pending_Amount": 0.0,
      "Invoiced_Amount": 0.0,
      "Paid_Amount": 0.0,
      "Currency": null,
      "Billed_Until": null
    },
    {
      "Property_ID": "54881868-2c19-4f11-a30a-4d0fa4a3d6c2",
      "Property_Name": "Cedarwood Unit 301",
      "Marketplace": "kijiji",
      "Active": false,
      "Published_Since": null,
      "Last_Action": "unpublished",
      "Last_Action_Date": "2026-08-05 10:12:41",
      "Days_Billed": 35,
      "Total_Billed": 35.00,
      "Pending_Amount": 0.0,
      "Invoiced_Amount": 5.00,
      "Paid_Amount": 30.00,
      "Currency": "CAD",
      "Billed_Until": "2026-08-05 00:00:00"
    }
  ]
}

Column meanings: Active is the live state right now; Days_Billed / Total_Billed are sums over the filtered period; Pending / Invoiced / Paid split that total by billing status; Billed_Until is the end of the last billed period. Free marketplaces appear with Total_Billed: 0 and Currency: null.

Field reference

updated_since is not supported on this report (see Incremental sync).

Billing Ledger

Charge lifecycle: pending (created the moment you publish) → invoiced (our billing cron pushed it to Stripe — Stripe_Invoice_ID + Invoiced_At are set) → paid (payment confirmed — Paid_At set). A charge Stripe rejects becomes failed (it is retried; if it stays failed, contact us).

GET /reports/billing
Authorization: Bearer lsy_live_…

GET /reports/billing?company_id=47
Authorization: Bearer <token>
X-Company-Password: <password>

Optional filters: start_date / end_date (on Created_At), status, property_id, plus page/page_size. An unknown status returns 400 — status must be one of: failed, invoiced, paid, pending.

Response 200 OK — real example, trimmed to one row

{
  "success": true,
  "report_type": "billing",
  "company_id": 47,
  "count": 38,
  "total_rows": 38,
  "summary": {
    "total_items": 38,
    "by_status": [
      { "status": "invoiced", "currency": "CAD", "items": 9,  "amount": 249.0 },
      { "status": "invoiced", "currency": "USD", "items": 29, "amount": 1232.1 }
    ],
    "by_marketplace": [
      { "marketplace": "craigslist", "currency": "USD", "items": 3, "amount": 609.0 },
      { "marketplace": "viewit",     "currency": "USD", "items": 4, "amount": 264.0 },
      { "marketplace": "zumperStandard", "currency": "CAD", "items": 6, "amount": 159.0 }
    ],
    "outstanding": [],
    "current_daily_run_rate": [ { "currency": "USD", "amount": 0.7 } ],
    "projected_monthly":      [ { "currency": "USD", "amount": 21.0 } ],
    "active_paid_listings": 2
  },
  "data": [
    {
      "Billing_ID": 1261,
      "Property_ID": "0097a517-7d15-4d8a-886f-aecc41ed8690",
      "Property_Name": "Atlanta Unit 300",
      "Marketplace": "zumperStandard",
      "Billing_Type": "first_month",
      "Period_Start": "2026-08-14 19:23:15",
      "Period_End": "2026-09-13 19:23:16",
      "Days": 30,
      "Daily_Rate": 0.3,
      "Amount": 9.0,
      "Currency": "USD",
      "Status": "invoiced",
      "Stripe_Invoice_ID": "in_1U4WtrCWaiSNDissOs7DTodX",
      "Created_At": "2026-08-14 19:23:16",
      "Invoiced_At": "2026-08-15 02:00:45.624548",
      "Paid_At": null,
      "Updated_At": "2026-08-15 02:00:45.624548"
    }
  ]
}

Updated_At is the latest of Created_At, Invoiced_At and Paid_At; it is also the field behind the updated_since filter (see Incremental sync).

Reading the summary for cost control

• outstanding — pending + failed amounts not yet collected (empty = fully invoiced)
• current_daily_run_rate — what your currently live paid listings cost per day, today (a snapshot, independent of the date filters), with projected_monthly = ×30. If a client asks "what am I spending?", this is the number
• by_marketplace — where the money goes, largest first
• Billing_Type per row: first_month (30 days charged on activation), recurring (each subsequent 30-day block), final_proration (the last partial days when you unpublish)

Amounts are per company currency (CAD/USD by account country); accounts that switched currency show one summary line per currency.

Field reference

Properties Report

GET /reports/properties
Authorization: Bearer lsy_live_…

GET /reports/properties?company_id=128
Authorization: Bearer <YOUR_API_TOKEN>
X-Company-Password: <YOUR_COMPANY_PASSWORD>

Response 200 OK — real example

{
  "success": true,
  "report_type": "properties",
  "company_id": 128,
  "count": 10,
  "data": [
    {
      "Property_ID": "fe4280be-7443-43dc-8d8f-adeba83fe348",
      "Property_URL_Slug": "qa-api-elmwood-tower-unit-101",
      "Property_Name": "Elmwood Tower",
      "Unit_Name": "Elmwood Tower Unit",
      "Unit_Address": "789 Elmwood Tower Rd",
      "Unit_Type": "Apartment",
      "Unit_Status": "Active",
      "Unit_Publish_Status": "Unpublished",
      "Rental_Space": "Entire place",
      "Lease_Term": "Month to month",
      "Suite_Number": "101",
      "Postal_Code": "T2N 4L4",
      "Country": "Canada",
      "Days_Listed": 27,
      "Marketing_Start": "2026-07-30",
      "Date_Available": null,
      "Rent_Amount": 1900.0,
      "Bedrooms": 2.0,
      "Bathrooms": 1.0,
      "Parking_Stalls": 0
    }
  ]
}

Field reference

Known limitation: City and Province_State are empty on units created through the API (Unit_City / Unit_Province on the leads report are filled).

Leads Report

GET /reports/leads?start_date=2026-08-01&end_date=2026-08-31
Authorization: Bearer lsy_live_…

GET /reports/leads?company_id=128&start_date=2026-08-01&end_date=2026-08-31
Authorization: Bearer <YOUR_API_TOKEN>
X-Company-Password: <YOUR_COMPANY_PASSWORD>

Response 200 OK — real row, personal details anonymized

{
  "Application_ID": 109099,
  "Applicant_ID": 109308,
  "Person_ID": 119519,
  "Lead_Name": "Carlos Applicant",
  "Lead_First_Name": "Carlos",
  "Lead_Last_Name": "Applicant",
  "Lead_Email": "carlos.applicant@example.com",
  "Lead_Phone": "+15551230002",
  "Application_Status": "New Lead",
  "Applicant_Rating": 0,
  "Tenancy_Application_Status": "Not_Completed",
  "Lead_Approval_Status": "In review",
  "Unit_ID": "9f3c1a52-…",
  "Unit_Name": "Maple Court Unit 2",
  "Unit_Address": "Edmonds Station Bus Loop",
  "Full_Address": "0, Burnaby, British Columbia 10461",
  "Unit_City": "Burnaby",
  "Unit_Province": "British Columbia",
  "Unit_Publish_Status": "Unpublished",
  "Vacancy_Status": "Vacant",
  "Rent_Amount": 3000.0
}

Unit_ID (since 3.10) is the unit the lead came in for, including leads that have not booked a showing yet.

Application_Status uses the stage names in the lead-stages table (see Field Values); Prequalification_Result and include_answers are described under Pre-qualification above.

Field reference

Showings Report

GET /reports/showings?page=1&page_size=500
Authorization: Bearer lsy_live_…

GET /reports/showings?company_id=128&page=1&page_size=500
Authorization: Bearer <YOUR_API_TOKEN>
X-Company-Password: <YOUR_COMPANY_PASSWORD>

Response 200 OK — real row

{
  "Unit_ID": "5a1a83a6-2e11-4087-aedf-c33c2fabaf2d",
  "Unit_Name": "168 Sanford Ave S",
  "Unit_Address": "168 Sanford Ave S",
  "Suite_Number": "Unit 2",
  "Unit_Type": "House",
  "Unit_status": "Vacant",
  "Unit_publish_status": "Published",
  "Rent_Amount": 1749.0,
  "Bedrooms": 2.0,
  "Bathrooms": 1.0,
  "Square_Footage": 725,
  "Date_start": "2026-08-07 18:00:00",
  "Date_end": "2026-08-07 18:20:00",
  "Showing_Status": "Cancelled",
  "TeamMember": "Jordan Lee",
  "TeamMemberRol": "Member",
  "Lead_source": "Manual",
  "Lead_Source": "Manual",
  "Days_listed": 48
}

One row per showing

Each row is one showing. Showing_ID is unique and is the key for reconciling with your records. Event_ID / Event_Name identify the booking link the showing was booked through. Booking_Scope:

The unit columns (Unit_ID, Suite_Number, Unit_Address, rent, bedrooms…) describe the unit the prospect actually booked, and Unit_ID matches Unit_ID on the same lead in /reports/leads. Until 3.7, rows from building-level links showed the building's first unit and lead columns could be copied from another showing at the same time slot; both fixed 2026-10-21 (re-pull if you cached earlier).

Real row from a building-level link:

{
  "Showing_ID": 60875,
  "Event_ID": 4530,
  "Event_Name": "880 Colborne Road",
  "Booking_Scope": "building",
  "Unit_ID": "251399cc-72e0-4582-ae35-d7f7661846a3",
  "Suite_Number": "406",
  "Application_ID": 130007,
  "Date_start": "2026-10-18 13:30:00"
}

Also on every showings row: Showing_Feedback (Positive, Negative, Not Attended, No Response, Not Reconfirmed), the lead columns (Person_ID, Application_ID, Lead_Name, Lead_First_Name, Lead_Last_Name, Lead_Email, Lead_Phone, Application_Status, Applicant_Rating, Tenancy_Application_Status, Lead_Approval_Status, Lead_Note) and the unit columns listed in the field reference below. /reports/showings has Lead_Source (where the lead came from, the same name as in /reports/leads) and Lead_source, a deprecated alias kept so existing integrations keep working. Use Lead_Source.

All five reports share the envelope (success, report_type, company_id, count, total_rows, data, optional pagination) and the same authentication as every other endpoint (an API key, or the legacy token + X-Company-Password).

Field reference

Column reference

Every column each report returns, with its type. The same definitions are in openapi.yaml (PropertiesReportRow, LeadsReportRow, ShowingsReportRow), so a generated client and this table always agree. A column marked "only sometimes present" appears when its feature applies (for example Updated_At once incremental sync is available, Rent_Market when the account uses market rent, Prequalification_Answers with include_answers=true).

A few names repeat across reports with a different meaning; read each table for its own report:

• Property_ID is the unit's UUID in /reports/properties and the building's integer id in /reports/showings. Join units on Unit_ID.
• Tenancy_Application_Status is Completed / Not_Completed (the form) in /reports/leads, and the document review status (Verified, Unverified, Incomplete, Reject, Not_Completed) in /reports/showings.
• Unit_Status in /reports/properties is Active / Archived; Unit_status in /reports/showings is the unit's vacancy text.
• Application_Status uses the partner names in /reports/leads and the dashboard names in /reports/showings (see "Lead stages: two sets of names" in section 11).
• Dates in /reports/leads and /reports/showings are YYYY-MM-DD HH:MM:SS; Date_Available and Updated_At in /reports/properties are ISO 8601 with a T and no offset. Showing times (Date_start, Date_end) are in the account's local time.

GET /reports/properties (54 columns, in the order they are returned)

GET /reports/leads (35 columns, in the order they are returned)

GET /reports/showings (50 columns, in the order they are returned)

9Webhooks API

Push delivery instead of polling. The mechanism — registering one endpoint, the signed delivery format and the retries — is the same for both APIs; what changes is which events each API can receive.

Leasing events. They use the same names and values as the Leasing API (section G5), and their full schemas are in openapi.yaml (ApplicationStageChangedEvent, ApplicationDecisionChangedEvent, ScreeningStatusChangedEvent, LeaseStatusChangedEvent, DocumentStatusChangedEvent). Leasey compares each record with the last state it announced to you, so a record that is touched without changing stage, decision or status sends nothing. They start from the moment you subscribe: the history is not replayed (read it with the Leasing API), and they arrive within about 10 minutes of the change. A previous value is null when the record is new to your webhook. Delivery is at least once: deduplicate on the record id, the new value and changed_at.

{
  "id": "msg_48213",
  "event": "application.stage_changed",
  "created_at": "2026-11-06T15:05:02Z",
  "data": {
    "application_id": 130625,
    "applicant_id": 130558,
    "person_id": 142403,
    "property_id": "e00b719c-0208-4d0d-be9e-d1cda7584a14",
    "changed_at": "2026-11-06T15:00:41Z",
    "stage": "signing_lease",
    "stage_label": "Signing Lease",
    "archived": false,
    "previous_stage": "application_in_review",
    "previous_archived": false
  }
}

Register Endpoint

PUT /webhooks
Authorization: Bearer lsy_live_…
Content-Type: application/json

{
  "url": "https://partner.example.com/leasey/webhooks",
  "events": ["unit.published", "unit.unpublished", "lead.received"]
}

{
  "company_id": 135,
  "password": "<your API password>",
  "url": "https://partner.example.com/leasey/webhooks",
  "events": ["unit.published", "unit.unpublished", "lead.received"]
}

Response — the secret appears only when first created or when you send "regenerate_secret": true

{
  "success": true,
  "webhook": {
    "url": "https://partner.example.com/leasey/webhooks",
    "events": ["lead.received", "unit.published", "unit.unpublished"],
    "is_active": true
  },
  "secret": "whsec_9f2c…",
  "secret_note": "Store this secret now - it is shown only once. Use it to verify the webhook-signature header."
}

Rules: the URL must be HTTPS; events must be a non-empty subset of the table above; send "is_active": false to pause delivery without losing the config.

GET /webhooks
Authorization: Bearer lsy_live_…

Legacy credentials: GET /webhooks reads the company password only from the password query parameter (it does not read the header).

{
  "success": true,
  "webhook": {
    "url": "https://partner.example.com/leasey/webhooks",
    "events": ["lead.received", "unit.published", "unit.unpublished"],
    "is_active": true,
    "created_at": "2026-08-27T00:43:22.134307",
    "updated_at": "2026-08-27T00:43:22.134307"
  },
  "recent_deliveries": []
}

Each entry in recent_deliveries looks like this (a delivery that failed once and is waiting for its retry):

{
  "id": 841,
  "event": "unit.published",
  "status": "pending",
  "attempts": 1,
  "response_code": null,
  "last_error": "HTTPSConnectionPool: Max retries exceeded",
  "created_at": "2026-08-26T23:44:19.406130",
  "delivered_at": null
}

status is pending (queued or between retries), delivered (your server answered 2xx — delivered_at set) or failed (all 5 attempts exhausted). If no webhook is registered yet, the response is 200 with "webhook": null and a hint to register one.

Events are delivered by a job that runs every 5 minutes, so expect up to ~5 minutes between the action and the delivery.

Delivery format and signature

Events are HTTPS POSTs (JSON), signed per the Standard Webhooks spec:

POST <your url>
webhook-id: msg_841
webhook-timestamp: 1756224000
webhook-signature: v1,K5oZfzN95Z9UVpg…

{
  "id": "msg_841",
  "event": "unit.published",
  "created_at": "2026-08-26T15:04:05Z",
  "data": {
    "property_id": "e6bc6604-1e7f-451f-8014-3560620a0489",
    "marketplace": "kijiji",
    "active": true,
    "charge": { "type": "first_month", "amount": 22.20, "currency": "USD", "period_days": 30 }
  }
}

A lead.received delivery carries the same fields as /properties/leads, so one parser serves both the pull and the push path. An unit.unpublished delivery has the same data shape as unit.published minus the charge (active: false).

A lead.received delivery looks like this (data has the same fields as GET /properties/leads):

{
  "id": "msg_843",
  "event": "lead.received",
  "created_at": "2026-08-26T21:15:02Z",
  "data": {
    "application_id": "117278",
    "application_id_number": 117278,
    "person_id": "128338",
    "person_id_number": 128338,
    "property_id": "80240cf8-0666-484a-af80-02d6a2133522",
    "source": "manual",
    "first_name": "Maria",
    "last_name": "Prospect",
    "email": "maria.prospect@example.com",
    "phone": "+15551230001",
    "status": "Booked",
    "date_created": "2026-08-26T21:13:39.434000",
    "property_name": "40 Ashley St",
    "property_address": "40 Ashley St",
    "city": "Hamilton",
    "province": "Ontario",
    "rent_amount": "2,249",
    "rent_amount_number": 2249
  }
}

data.status uses the same stage names as Application_Status in /reports/leads: New Lead, Booked, Application In Progress, Application In Review, Signing Lease, Active Tenants (see the lead-stages table in Field Values).

Verify the signature

import base64, hashlib, hmac

def verify(secret, headers, raw_body):
    key = secret.split("_", 1)[-1].encode()
    signed = "{}.{}.{}".format(headers["webhook-id"],
                               headers["webhook-timestamp"], raw_body)
    expected = base64.b64encode(
        hmac.new(key, signed.encode(), hashlib.sha256).digest()).decode()
    return hmac.compare_digest(expected, headers["webhook-signature"].split(",", 1)[1])

Retries and reliability

• Respond 2xx within 8 s to acknowledge. Anything else is retried.
• Backoff: +2 min, +10 min, +30 min, +2 h — 5 attempts total, then the delivery is marked failed (visible in GET /webhooks).
• Deliveries may arrive out of order and, rarely, more than once — de-dup by the id field (for leads, data.application_id also works).
• lead.received starts with the first delivery run after you register; leads created before that run are not sent. History is not replayed: use GET /reports/leads (or GET /properties/leads on the Syndication API) for backfill.

Testing your webhook

• Before your receiver exists, point the webhook at a request inspector (webhook.site) to see real deliveries with headers.
• Use a tunnel (ngrok) to test your own receiver locally.
• GET /webhooks shows each delivery's status and the response code your URL returned.

10Property Object Reference

Fields accepted in the property object (create and update). Your side maps its own model into these; Leasey maps them onward into each marketplace feed.

Required on create

POST /properties with a name that already exists in your account answers 409 Conflict with the existing property_id (unit names are unique per account).

Optional — identity, location & building

suite_unit, postal_code. For multi-unit properties: building_name + number_of_units (groups the unit into a building, created if it doesn't exist — response echoes building_id); building_id (attach to an existing building instead of matching by name); building_amenities — array of {id, value} (1 included · 2 available · 3 not available), requires building_id/building_name/number_of_units in the same request; floorplan_id or floorplan (string name or object {name, bedrooms, bathrooms, size_sqft}).

Building amenity id catalog

Buildings created via building_name inherit the unit's location (address, city, province, country, postal code, coordinates); a building that already exists with blank location fields is completed from the next unit (existing values never overwritten).

Optional — commercial

rent_amount (string or number), security_deposit, rent_payment_frequency (daily|weekly|bi-weekly|monthly|yearly|one-time), renewal_frequency (fixed term|month to month|fixed term, renewing month-to-month), date_available (YYYY-MM-DD), rental_application_url + use_custom_application_link: true — your own application form URL; leads on marketplaces are sent to it instead of Leasey's application flow.

Optional — physical

unit_type (apartment|house|townhouse|duplex/triplex|basement suite|room only|other), rental_space (entire place|partial place), bedrooms, bathrooms, size_sqft, furnishing (1 furnished · 2 unfurnished · 3 partially), parking_stalls, storage_available, max_occupancy.

Optional — content

description (plain text; shown on marketplaces), photos (array of {url} — first photo is the cover; HTTPS required), features (array of {id, value} — full catalog below), restrictions (array of ids: 1 no dogs · 2 no smoking · 3 no short-term · 4 no subletting · 5 no cats).

Optional — people

owner_contact — object with first_name, last_name, email, phone, dial_code, notify_email (bool), notify_sms (bool); it is the notification recipient for every notification about the unit (publish/unpublish, showing cancellations on deactivation, lead notices) when notify_email is true; the enable/disable payloads carry no email field.

team_members — assign existing staff to the unit or create new ones in the same call. Each entry is either an existing member ({"team_member_id": 45}) or a new one by email:

"team_members": [
  { "team_member_id": 45 },
  {
    "email": "agent@acmepm.com",
    "first_name": "Ana",
    "last_name": "Ruiz",
    "role_id": 3,
    "is_admin": false,
    "timezone": "America/Vancouver"
  }
]

A member created through the API is Admin by default. To set another role use, in order of precedence: role_id, role by name ("Admin", "Member", "Showing Coordinator" or any custom role of your account), or is_admin: false. timezone is optional (your account's default is used when omitted). The response echoes role_id, role and is_admin. An unknown role fails that entry (in skipped) without aborting the rest. Changing the role of an existing member is not done here. The response echoes what happened to every entry:

"team_members": {
  "assigned": [45, 61],
  "created": [
    {
      "team_member_id": 61,
      "user_id": 5120,
      "person_id": 131044,
      "email": "agent@acmepm.com",
      "already_existed": false
    }
  ],
  "skipped": []
}

owner_user_id — assign the unit to a specific user of your account (validated against your company_id); defaults to your account's admin. marketplaces — publishing to marketplaces, its pricing and billing are documented in the Syndication API tab.

Marketplace-specific formatting (photo sizes, description length limits, feed-specific enums) is handled by Leasey — you send the canonical fields above once.

Feature (unit amenity & utility) catalog

Each features entry has an id and a value: 1 = Included in rent · 2 = Available, not included · 3 = Not available. Only include features you want to set — unspecified features default to not available.

Example: {"id": 6, "value": 1} = dishwasher included in the rent; {"id": 20, "value": 2} = electricity available but paid separately.

11Field Values (Enums)

Use these for filters, badges and validation. They come from the live data, not from a spec — if a new value appears it will be additive.

/reports/showings

/reports/leads

/reports/properties

Lead stages: two sets of names

In the Leasing API the stage is a code and stage_label carries the /reports/leads name.

Until 3.10 the Booked stage was called Application Received in /properties/leads and in the lead.received webhook, and /reports/leads returned the raw value 3. Integrations that mapped the old name should now map Booked.

12Error Reference

Every error carries code and request_id; see Errors & Troubleshooting for the format and the complete list of codes below.

Error codes

Per-marketplace entries inside a 200 response carry their own status: "error" with code: payment_method_required or message: "Unknown marketplace."; they are not HTTP errors.

13Support

Before reporting an outage, check https://status.leasey.ai.

API access is included with every Leasey account, with no usage quota.

The Syndication API for platforms that resell Leasey syndication to their own customers (organizations, white-label) is the Custom plan; see Pricing.

14Changelog