API Report Card · Listings, Applications & Tenant Screening · Methodology v1.1
Tenant Turner
Where the points came from.
Five categories, each worth a fixed share of the 100 points. A category earns the fraction of its checks it passes, times its maximum.
Functional Coverage
Design & Reliability
Access Control
Docs & AI-Ready
Access & Cost
Letter grades are absolute, never curved.
The same numeric bands apply to every platform. Nothing here is scored relative to the rest of the board.
What this means for you.
One paragraph per category, in plain language.
1 · Functional Coverage
You can read almost everything Tenant Turner knows about your listings, leads and showings, and you can publish and activate a listing end to end. What you largely cannot do is change things. There is no cancelling or rescheduling a showing, no updating a lead, no writing back showing feedback, and no turning self-access viewing on or off. Event coverage is genuinely strong, with 21 signed triggers, but for anything beyond listings you will be reading Tenant Turner and acting somewhere else.
2 · Design & Reliability
The shape of the API is fine, and the pagination and incremental filters are well behaved. The problems are the ones that bite in production. Money-adjacent numbers arrive as strings even though you write them as numbers, so every rent and deposit needs parsing and your types will not round-trip. Retrying a failed showing creation can double-book a prospect, because nothing prevents duplicates. Nothing tells you what the rate limit is or when you hit it. And you cannot quote a request id to support.
3 · Access Control
The area with real operational risk. There is one key, it can do everything your account can do, and you cannot give a contractor, a vendor or an AI agent a narrower slice. If you hand that key to an automation and it misbehaves, your only lever is to refresh the key, which instantly breaks every other integration using it. With no sandbox either, there is nowhere safe to develop.
4 · Docs & AI-Ready
For the REST endpoints, a developer or coding agent handed the OpenAPI file can build quickly. Everything around it is thin. The docs sit behind a login, so a coding tool cannot reach them unaided. Webhooks, the most useful capability here, have no documentation at all, so payload shapes must be reverse-engineered. And there is no changelog, so the first sign something changed will be your integration breaking.
5 · Access & Cost
Full marks. Nothing stands between you and the API. If you are a customer on any plan the key is already sitting in your portal, it costs nothing extra, and you can start building this afternoon.
Every check, and why it scored that way.
The same 27 checks are applied to every platform. What changes is which are N-A and what the core objects mean for that kind of software. Each mark below is quoted from the run's own report.
Category 1 · Functional Coverage
3.8 / 15Object coverage
weighted coverage = 64.7% (11.0 of 17 weight). Every critical object is present, but two of the three are read-mostly. [swagger.json paths /v1/properties (post,get), /v1/properties/{propertyId} (put,get), /v1/multifamilyproperties, /v1/applications (post,get), /v1/applications/{applicationId} (get), /v1/showings (get,post), /v1/showings/{showingId} (get); live GET /v1/properties → 189 records, 2026-09-01]
Core operational actions
weighted coverage = 46.4% (6.5 of 14 weight), below the 0.50 threshold. Listings are fully writable (1.0); lead capture plus pre-qualification but no lead update (0.5); showing creation but no reschedule (0.5); self-access credential issuance absent (0.0); showing feedback read-only (0.0); syndication limited to one boolean (0.5). Documentation-graded — no live write was authorized. [swagger.json: PropertyPostPutRequest contains 31 writable fields; enableSelfAccessViewings, selfAccessViewingType, selfAccessViewingInstructions, enableShowings, showingInstructions, enableWaitlist appear in ApiProperty responses but are absent from the write schema]
Delete or lifecycle actions
weighted coverage = 33.3% (4.0 of 12 weight), and a critical lifecycle action is absent: a showing cannot be cancelled or rescheduled through the API. Only property /activate and /deactivate exist; there is no DELETE verb in the specification. Documentation-graded. [swagger.json paths: /v1/properties/{propertyId}/activate (put), /v1/properties/{propertyId}/deactivate (put); /v1/showings/{showingId} exposes get only]
Change notification
(reconciled; run 1 marked yes, runs 2 and 3 partial) — weighted coverage = 100% of the critical-plus-important state changes fixed in Step 1. 21 event types are offered, covering lead creation, qualification and disqualification, viewing scheduled / confirmed / cancelled / no-show / feedback, rental activation and deactivation, and lockbox code sent. Exact limitation: the check requires documented events, and no payload schema, event reference or developer-facing event list is published anywhere — the 21 triggers are discoverable only by opening the webhook form in the product, so a consumer cannot be built from documentation alone. Efficient incremental polling exists as a second mechanism and was verified live. [app.tenantturner.com/api/create-webhook, observed 2026-09-01: Lead Created, Lead Archived, Lead Unarchived, Lead Declined, Lead Qualified, Lead Disqualified, Lead Contact Info Updated, Tenant Selected, Viewing Confirmed, Viewing Requested, Viewing Cancelled, Viewing No Show, Viewing Scheduled, Viewing Feedback, Rental Activated, Rental Deactivated, Rental Off Waitlist, Rental On Waitlist, Rental Ready To Activate, Rental Ready To Deactivate, Lockbox Code Sent; live SinceDateUpdated filter honored exactly — 2394 → 634 → 54 records as the cutoff tightened]
Category 2 · Design & Reliability
4.2 / 10Modern API conventions
resource-oriented REST over JSON with standard verbs and a /v1 path version. [swagger.json, OpenAPI 3.0.1, 14 paths using GET/POST/PUT; live GET /v1/properties → 200]
Consistent typing
seven core fields are written as numbers and read back as strings on the same resource: squareFootage and bedrooms (integer/int32 → string), and bathrooms, rentAmount, depositAmount, applicationFee, leaseProcessingFee (number/double → string). Confirmed live. The response envelope also differs from the published sample: the API returns Data (PascalCase) where the documentation shows data. [swagger.json, PropertyPostPutRequest vs ApiProperty; live GET /v1/properties 2026-09-01 returned RentAmount, DepositAmount, Bedrooms, Bathrooms, SquareFootage as JSON strings]
Structured errors
a structured JSON body and correct HTTP status semantics are present (404 for a missing id, 400 for a type mismatch, 422 for a missing required parameter, 401 unauthenticated), but there is no stable machine-readable error code: the statusCode field merely echoes the HTTP status. Error shapes also vary across endpoints — PascalCase {"StatusCode":404,"ErrorMessages":[...]} on some paths and camelCase {"statusCode":400,"errorMessages":[...]} on others — and 400s return the uninformative "General error.". GET /v1/nosuchresource returns 404 with an empty body. [swagger.json ApiErrorResponse; live error battery 2026-09-01]
Duplicate prevention
no idempotency keys, request identifiers or equivalent mechanism is documented, and POST /v1/showings and POST /v1/applications are operationally consequential (creating a showing initiates prospect coordination). A retried create can duplicate. Zero specification hits for "idempot". Documentation-graded. [swagger.json, full-text scan 2026-09-01]
Graceful handling under load
no documented 429, no Retry-After, no backoff guidance; "429" appears in the specification only as a member of the HttpStatusCode enum. Throttling behaviour is silent: a bounded 25-request probe returned 25× HTTP 200 with no rate-limit headers of any kind. [live probe 2026-09-01; swagger.json scan]
Pagination for large collections
cursor pagination on /v1/showings and /v1/applications works well and returned totalCount 2394, a 144-character nextPage token, and disjoint ascending pages across two hops. But ordering stability is nowhere documented (only observed), and /v1/properties and /v1/multifamilyproperties have no pagination at all — the properties list returned all 189 records in a single 443 KB response with no documented cap. [live 2026-09-01; swagger.json list parameters]
Bulk or incremental export
incremental sync works on standard list endpoints via SinceDateUpdated plus cursor pagination, and /v1/properties/sync returns a lightweight address list, but there is no dedicated bulk or async export path and history is capped at two years: SinceDateUpdated is mandatory and rejected beyond that window, so a full historical backfill of showings or applications is impossible. [live: GET /v1/showings without the parameter → 422 "SinceDateUpdated is required and must be less than 2 years ago."]
Webhook security and delivery reliability
payloads are signed (X-Payload-Signature, HMAC-SHA256 over the payload using the account's private key) and per-webhook delivery logs exist in the product, but no retry policy and no replay or idempotency guidance for consumers is documented anywhere, and webhooks are absent from the developer documentation entirely. Documentation- and product-interface-graded; step 8 not run. [app.tenantturner.com/api/key; app.tenantturner.com/api/webhooks Logs column, observed 2026-09-01]
Concurrency and conflict control
no ETag or If-Match, no version field, no documented 409 semantics, and no documented concurrency limits. No validator headers were returned on any live response. [swagger.json scan: zero hits for etag, if-match, concurren; live header inspection 2026-09-01]
Versioning and backward compatibility
an explicit /v1 path version exists, but no backward-compatibility policy defining breaking versus non-breaking changes and no deprecation window or notice mechanism was found. Zero specification hits for "deprecat" or "sunset". [swagger.json info.version "v1"; documentation site has no policy page]
Request traceability
responses carry no API request or correlation identifier; the only identifiers present are x-azure-ref (Azure Front Door infrastructure) and Request-Context (an Application Insights application id, constant across requests). A genuine first-party trace mechanism does exist in the product — /api/logs listed this run's exact calls with response code, verb, route and timestamp — but it exposes no unique per-request id and is not mentioned in the developer documentation. [live headers 2026-09-01; app.tenantturner.com/api/logs observed showing 200 GET /v1/properties/sync, 422 GET /v1/applications, 404 GET /v1/properties/999999999]
Service availability and status transparency
a public Atlassian Statuspage with per-component status, 90-day uptime of 100.0%, and dated incident history. [status.tenantturner.com, observed 2026-09-01: components Tenant Turner, CodeBox, SentriLock]
Category 3 · Access Control
1.3 / 5Read-only credentials
a single account key carries the full read and write surface; no read-only credential or read-only integration identity is offered. [app.tenantturner.com/api/key, observed 2026-09-01: one key, no scope or permission controls]
Scoped credentials
the key cannot be restricted to particular resources, actions or a role. It is a single all-powerful account credential. [app.tenantturner.com/api/key]
Multiple keys
the account holds exactly one API key, presented as "your account specific private key", with a single "Refresh API Key" control; there is no facility to issue distinct keys per integration. A separate webhook signing key exists but is a signing secret, not a second API credential. [app.tenantturner.com/api/key]
Rotation and revocation
self-serve rotation via the "Refresh API Key" button, with explicit vendor instruction to use it. [app.tenantturner.com/api/key: "Keep this key secret and refresh the key if you feel your private key is no longer private."]
Test and production isolation
no sandbox or separate test environment is evidenced anywhere in the documentation, the specification (no servers block) or the product.
Category 4 · Docs & AI-Ready
1.3 / 5Complete self-serve reference
the Redocly reference is well structured and example-rich, with request and response samples for all 14 endpoints. Three material limitations: it is not publicly accessible (requires a customer login or a Partner API key; /docs 302s to OIDC and /swagger/v1/swagger.json returns 401); webhooks are entirely undocumented despite being a shipped feature with 21 event types, so payload shapes must be reverse-engineered; and the reference is inaccurate in at least two respects — SinceDateUpdated is marked optional but is enforced as required, and response samples show a data envelope where the API returns Data. [api.tenantturner.com/docs; live 422 and live GET /v1/properties, 2026-09-01]
Reliable machine-consumable integration path
(reconciled; run 1 marked yes, runs 2 and 3 partial) — an OpenAPI 3.0.1 specification covers all 14 paths with full request and response schemas. Exact limitation: three defects each break a generated client and require manual correction — there is no servers block, so generated code has no base URL; SinceDateUpdated is declared optional but enforced as required, so generated calls return 422; and responses are documented with a data envelope where the API returns Data, so deserialization fails. No official SDK and no MCP server was found; the PHP SDK on GitHub is published by TenantCloud, a different vendor, and does not claim official status, so it is not credited. [api.tenantturner.com/swagger/v1/swagger.json]
AI-readable documentation
no llms.txt or llms-full.txt on either the marketing, help or API domain (all 404 on 2026-09-01), no per-endpoint Markdown, and no downloadable plain-text or Markdown documentation corpus. The vendor's July 2026 announcement claims documentation "better formatted for both human developers and AI agents", but no qualifying retrieval artifact was found. The OpenAPI file is credited under C4.2 and is not counted twice here.
Kept current
no changelog, no release notes, no versioning notes and no deprecation guidance anywhere on the documentation site; zero specification hits for "deprecat" or "sunset". The single July 2026 press release is an announcement, not an ongoing currency mechanism, and gives a reader no way to learn that an endpoint changed.
Category 5 · Access & Cost
15 / 15Self-serve API key
the key is generated and visible in the customer portal with a self-serve "Refresh API Key" control. No sales call, support ticket or vendor approval step is involved; this operator's key was present and active, and authenticated successfully on the first live call. [app.tenantturner.com/api/key, observed 2026-09-01; live GET /v1/properties → 200]
Not commercially gated
the vendor states the API update is "available to all customers at no cost", and the published plan comparison ties no API or integration capability to a tier. [Tenant Turner press release, 2026-07-06; tenantturner.com/plans-pricing/]
What works
- Free on every plan, with the key already sitting in your portal
- 21 signed webhook events, enough to keep a CRM current in near real time
- Cursor pagination and incremental filters that behave well under test
- Full write control over listings, including activate and deactivate
- Public status page showing 100% uptime over 90 days
What to watch
- One all-powerful key: no read-only option, no scoping, no second key
- A showing cannot be cancelled or rescheduled, and a lead cannot be updated
- Rent and deposit amounts write as numbers and read back as strings
- No documented rate limit, and no idempotency, so a retry can double-book
- Webhooks are undocumented, so payload shapes must be reverse-engineered
The bottom line for a property manager
Tenant Turner has done the hard part of access exactly right: the API is free, on every plan, and the key is already in your portal. What you get for that is a solid read surface over your listings, leads and showings, full write control over listings themselves, and 21 signed webhook triggers. If your goal is getting your leasing data out and into something else, you can build that today, though you will be reverse-engineering the event payloads and correcting the generated client as you go. What you cannot build is write-back automation for the things that move fastest: any workflow ending in 'and then change it in Tenant Turner' ends with a person in the portal instead. Read the score for what it measures. This rates API buildability, not the product, and Tenant Turner is a leasing tool that clearly does its job. Treat the API as a very good read-and-notify feed with a narrow write path for listings.
Check it yourself.
Both files behind this page, in full.
Tenant Turner’s full report
The complete markdown report this page is built from, including the evidence packet, the run metadata and every check in full.
Download the Tenant Turner reportThe grading file
The exact rubric behind every score on this page. Same file, every platform. Run it yourself and compare.
Download the methodologyFound a factual error in your grade?
Tell us and we will fix it. Every mark on this page traces to a specific piece of first-party evidence or a live API call, and the full report is published so you can see exactly what was checked and what it was checked against.
Confirmed factual errors are corrected immediately.
Everything else waits. We do not rescore piecemeal on request, because a board where some vendors have been re-run and others have not is not a fair comparison. Shipped improvements, changed documentation and disagreements about judgement all go into the next full rerun.
Contact us with a factual errorMethodology inspired by SaaStr’s AI Agent API Report Card. Sponsored by Column.