API Report Card · Listings, Applications & Tenant Screening · Methodology v1.1
ShowMojo
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 push listings into ShowMojo from your PMS and pull leasing activity back out in bulk. Beyond that the API does not let you operate the product. Every showing action your staff performs all day, confirm, cancel, reschedule, mark a no-show, is something the API will tell you happened and will not let you cause. There is also no way to create or update a lead. And because listings have no updated-since filter and no webhook of their own, detecting that a listing changed means re-pulling the whole collection.
2 · Design & Reliability
The strongest category, and the parts that exist are mostly well built: clean typing that matched live responses field for field, an honest status page, a request id on every response, and an export that genuinely honors date ranges. The operational gaps are what bite in production. No rate limit is documented and 60 rapid requests returned no rate-limit headers at all, so you cannot tell what the ceiling is or what happens when you hit it. The main listings call returns everything in one unbounded response. A failed authentication hands your code an empty body instead of an error.
3 · Access Control
The weakest area and the one with real risk attached. There is exactly one kind of key, it can do everything the API can do including overwriting your entire listing portfolio, and the account owner confirmed there is no read-only option. So if you want to give a contractor, a vendor or an AI agent access to read your showing data, the only credential you can hand over is one that can also rewrite your listings. You can generate a fresh token yourself, but nothing documents that doing so kills the old one.
4 · Docs & AI-Ready
A developer can read the listings and properties documentation and build against it. Pointing an AI coding assistant at it is another matter: no OpenAPI spec, no SDK in any language, no MCP server, and no llms.txt. The endpoint details are client-rendered, so fetching a documentation page returns prose with the parameter and schema tables missing, which is exactly how a coding tool reads a page. The report export, the highest-value data path, publishes no column documentation at all.
5 · Access & Cost
Full marks. Credential creation is self-serve, with no sales call, support ticket or approval step. The pricing page itemizes every other add-on, down to per-device hardware fees, and never lists the API as a tier feature or upsell. This single category accounts for nearly two-thirds of the points ShowMojo earned.
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
1.9 / 15Object coverage
weighted coverage = 47.6% (10.0 ÷ 21). Listings are fully covered: GET /api/v3/listings with a fields selector and a 40-plus-field typed schema, GET /api/v3/listings/:uid, and POST import; live-verified 2026-09-02, returning 24 listing records matching the published schema. Everything else is materially read-only or absent. Properties are explicitly "read-only access" (/docs/legacy/properties). Leads, prospects and showings exist only as report rows and webhook payloads — live-verified: detailed_prospect_data returned prospect/showing records carrying created-at, contact, showtime, showing method, no-show, current status, cancelled-by, lead source, team member, notes and custom pre-screening answer fields — but there is no lead or showing resource endpoint. Digital access is read-only reporting with no way to trigger code distribution. Applications, documents and lease lifecycle are absent. Below the 0.50 floor.
Core operational actions
(documentation-graded) — weighted coverage = 21.4% (3.0 ÷ 14). The only operator-callable write in the entire API is listing import: POST /api/v3/listings (and the legacy POST https://showmojo.com/api/v1/listings), up to 100 listings per request, upserting by code, uid, or mls_id. Two critical write workflows are absent: there is no endpoint to create or update a lead, and none to schedule, confirm, or cancel a showing — the product's namesake action. The Zapier surface adds POST /zapier/listings, but ShowMojo states it "is used exclusively by the Zapier integration and is not intended for direct use outside of Zapier," so it is not an operator-available action. Marked no on both triggers: below 0.50 and critical write workflows absent. Unanimous across all three runs.
Delete or lifecycle actions
(documentation-graded) — weighted coverage = 18.8% (3.0 ÷ 16). Listing on/off-market status is settable through import via status (STATUS_ACTIVE / STATUS_INACTIVE), documented in the import schema and in knowledgebase.showmojo.com/take-imported-listings-off-the-market. Every other principal lifecycle change — cancel, confirm, reschedule, no-show, blacklist/deny, hide/restore — exists in ShowMojo and is reported through the webhook action list, but no endpoint performs any of them. Marked no on both triggers. Unanimous.
Change notification
(push half documentation-graded) — weighted coverage = 80.0% (12.0 ÷ 15). The Leads and Showings webhook fires "whenever a lead or showing is created, updated, or changed" and its published event.action reference enumerates 120-plus actions covering the showing- and prospect-side state changes: confirm, confirm_automatically, cancel, uncancel, auto_cancel_no_reply, reschedule_request, set_no_show, undo_no_show, blacklisted_prospect, showing_denied_pets / _income / _move_in_date, plus document-verification, pre-screening and lockbox-code events. Zapier adds new_showing, cancel_showing, blacklisted_showing, denied_showing. Listing state changes are not covered and cannot be efficiently polled: no listing webhook is evidenced anywhere, and live testing confirmed updated_since, updated_after, since, modified_since and status are all silently ignored on the listings endpoint, each returning the identical unfiltered 24 records. The critical listing-change item scores 0.0, landing coverage in the partial band.
Category 2 · Design & Reliability
6.7 / 10Modern API conventions
Resource-oriented REST over HTTPS returning JSON, with conventional collection and item paths, live-verified. Mixed conventions hold it below yes: report reads are POST with application/x-www-form-urlencoded bodies; listing create-and-update is a single overloaded POST upsert; no PUT, PATCH or DELETE verb appears anywhere in the API; and the import page advertises a stray "Second Endpoint" on /api/v1/ inside the v3 documentation. Unanimous.
Consistent typing
The published schema is precisely typed (rent integer, plus_convertible boolean, lat float, available_date date, created_at/updated_at date-time, plus closed enums for status, general_type, housing_type, available_type, security_deposit_type, external_source). Live reads matched exactly on 2026-09-02: numeric fields returned as bare numbers not strings, booleans as true/false, and every observed enum value drawn from the documented set. Report payloads carry no published schema, but their observed value typing is consistent, including nullable booleans. Noted but not scored here: report endpoints use inconsistent key-naming across reports (snake_case versus Title Case with spaces), which hurts machine consumption but is not a typing defect, and the missing report schemas are charged in C4.1 rather than double-counted here. Unanimous.
Structured errors
Correct HTTP status semantics throughout, live-verified at 401, 404 and 422. JSON error paths return a consistent envelope with a usable human-readable message — {"response":{"status":"error","errors":"Listing not found"}} and {"response":{"status":"error","errors":"Max date range is 1 week."}}. Two limitations pin this at partial, and both partial triggers are met: no populated machine-readable error code exists anywhere — errors is free text an integration would have to string-match — and error shapes vary across endpoints, because the 401 returns Content-Type: text/html with a completely empty body. Unanimous.
Duplicate prevention
(documentation-graded) — The one consequential operator-facing write has documented natural idempotency: import matches on "one of provided IDs: code, uid, or mls_id" or an exact address match, and "If no match is found, a new listing is created," reinforced by the documentation home's "automatic deduplication by address, code, or MLS ID" and by a documented 409 guard against overlapping imports. The rubric expressly accepts natural idempotency. Limitations recorded: idempotency is client-dependent, holding only where the caller supplies a stable identifier, and no idempotency-key header exists as a fallback. Unanimous, though both graders noted this mark is the one most exposed by the write-test refusal, since it was never observed.
Graceful handling under load
No 429 is documented anywhere, no Retry-After guidance exists, and no numeric backoff advice is published. Live-verified: 60 rapid sequential requests all returned HTTP 200 with no rate-limit headers of any kind. The only related statement is contractual, not operational — ShowMojo "may set and enforce limits on your use of the API(s) … in our sole discretion" — which tells a builder a limit may exist but nothing about how it will surface or how to recover. Unanimous.
Pagination for large collections
Where pagination exists it is done properly: GET /api/v3/properties documents page and per_page with a max of 100, and live-verified it returns a complete envelope — {"page":1,"per_page":2,"total":0,"total_pages":1} — giving both a total-count signal and a page count, and correctly clamps an over-cap request. But the primary collection is unpaginated: GET /api/v3/listings documents only a fields parameter, and live-verified it ignores page and per_page entirely, returning the full collection as a bare JSON array. Report exports state outright that "The API does not support pagination," and one returned 258 KB in a single call. No stable-ordering guarantee is published anywhere. Unanimous, with both graders noting the no band's "unbounded/inconsistent behavior" language fits uncomfortably well.
Bulk or incremental export
A genuine bulk-export path that works. Eight named reports are documented with their endpoint names, each retrievable as JSON or CSV with start_date/end_date, plus POST /api/v3/reports/custom. Live-verified: all eight returned HTTP 200; the CSV variant returned Content-Type: text/csv with a proper header row; and date filtering is genuinely honored — listing_and_showing_metrics returned 227 rows for a 1-week window, 1,061 for 3 months, and 1,546 for 8 months. Full datasets are retrieved without per-record calls. Limitations noted: exports are unpaginated and synchronous with no async job mechanism, detailed_prospect_data is capped at a 1-week window, listing_performance ignores dates entirely, and the object endpoints have no updated-since parameter. Unanimous.
Webhook security and delivery reliability
(documentation-graded) — Retries are well documented: "Retries occur at: 5, 15, 45, 135, and 405 minutes" with "5 failed attempts = webhook is auto-disabled." Consumer guidance exists for ordering: "Out-of-order delivery is possible — use event.id to track sequence." What is missing is payload verification: authentication is a static Bearer token, not an HMAC signature over the body. A static shared secret is replayable and not tamper-evident — it proves the caller knows a secret, not that this payload is authentic and unmodified. The guidance also addresses sequence rather than explicit duplicate/replay handling, HTTPS is only "strongly preferred," and the Zapier path documents a contradictory policy of three attempts with polynomial backoff and no requeue. Unanimous.
Concurrency and conflict control
(documentation-graded; disagreement stands — see below) — Both prongs are documented for the write surface: explicit conflict semantics — "you'll receive an HTTP 409 Conflict response: Another import is currently in progress" — together with the documented concurrency behavior that imports must be serialized. Limitations recorded: this is a coarse account-level import lock, not per-record optimistic concurrency, and because import "replaces all existing listing information with the newly provided listing information," two integrators whose imports do not overlap in time will still silently clobber each other. Separately, live-verified on reads: responses carry an ETag and honor If-None-Match, returning HTTP 304 — useful for polling efficiency, though it is response caching rather than write-conflict control, and it is undocumented.
Versioning and backward compatibility
An explicit version identifier exists in the path (/api/v3/...), the documentation is version-labelled (Legacy "Version: 1.0.0", v4 "Version: 4.0.0"), and a successor is announced. What is absent is the contract: no definition of breaking versus non-breaking changes, no deprecation window, and no sunset notice policy. The legacy introduction offers only an informal assurance, and the terms point the other way, reserving the right to "modify, amend, or cease providing the Services … at any time and without prior notice." Unanimous.
Request traceability
Live-verified: every response carries x-request-id as a UUID, on success and on errors alike (a 200 listings read and a 404 both returned distinct identifiers), alongside x-runtime. The identifier is real and consistently present. It is partial rather than yes because it is undocumented: no page in the API documentation mentions x-request-id, and no guidance tells a builder to quote it to support. Unanimous.
Service availability and status transparency
status.showmojo.com is a public status page carrying both required elements: per-component uptime percentages (observed 2026-09-02: Codebox API 99.97%, ShowMojo Application 100% over the trailing 7 days) and a genuine incident history with dated, timestamped, individually resolved entries including duration and affected components. Noted: the monitored components are "Codebox API" and "ShowMojo Application"; the public REST API is not broken out as its own component, so an operator cannot tell from the page whether the graded API specifically is up. Unanimous.
Category 3 · Access Control
0.8 / 5Read-only credentials
First-party product-interface observation, 2026-09-02: the ShowMojo account owner, reporting from the logged-in Settings > Import credential page, states there is no read-only token option. Consistent with the documentation, which describes exactly one token used across reads and the import write, and with the knowledge base, which describes only token generation and no credential types. Not N-A: the API has a write path, so a read-only credential is a meaningful capability here. Unanimous.
Scoped credentials
A single all-powerful credential. Live-verified: the one listing-import token was used successfully against listings, properties and all eight report exports. The documented alternative is HTTP Basic auth using the operator's own ShowMojo login and password — the account holder's full interactive credentials. No scope, permission, role or resource restriction is offered or documented for an operator-issued credential anywhere in the documentation, the knowledge base, or the terms. The only scope construct in any ShowMojo material is the OAuth2 zapier scope, which is issued to the Zapier application and is not something an operator can mint for their own integration; the production token returns 404 against /zapier/me. Unanimous.
Multiple keys
could not access** — Whether an account can hold several distinct, separately revocable tokens is not stated in the API documentation, the knowledge base, or the terms, and the credential page is login-gated. The gated evidence was requested from the operator per methodology rule 4; the observation supplied covered read-only availability and token generation but did not address this. Circumstantial signals point both ways. Excluded from the category denominator and flagged rather than guessed. Unanimous.
Rotation and revocation
Self-serve issuance is confirmed by direct product-interface observation: the account owner can generate a new token themselves, with no vendor involvement, support ticket or approval step. But this check grades rotation and revocation, and neither is established: whether generating a new token invalidates the previous one is undocumented, and no revocation or delete control is evidenced anywhere in first-party material. A mechanism that may only add a credential rather than retire one does not demonstrably accomplish rotation, so an operator cannot assume a compromised token dies when a new one is issued. Present but materially limited.
Test and production isolation
No sandbox or separate test environment exists to grade. ShowMojo states plainly: "A testing sandbox is currently under development — real API requests may not function as expected." The documentation's mock-docs.showmojo.com host is a fixture backend for the docs, not an operator test environment: live-verified, it validates no credential whatsoever — a deliberately invalid token, an arbitrary Basic header and the real production token all returned HTTP 200 identically, while omitting the header returned 401 — and it returns the same canned schema examples to everyone, holding no account data. Recorded as a real hazard even though the check is N-A: because it accepts a live production token and returns success, it invites operators to paste production credentials into a documentation tool.
Category 4 · Docs & AI-Ready
1.3 / 5Complete self-serve reference
A real, publicly accessible reference exists and is better than the category average in places: authentication is stated per resource group, endpoints carry full parameter and response schemas with per-field descriptions and examples, and every endpoint ships worked request samples in six languages plus a live request control. Live reads matched the published listing schema field-for-field on types. The limitations are material. The report export — the primary bulk-data path — has no documented response schema at all: none of the eight reports publishes its columns, so the field names in this report had to be discovered by calling the endpoints. The v4 section is empty, containing only an introduction reading "Comming soon" [sic] with no endpoints. Doc/live divergences were observed: listing_group_name, showing_types, contact_info, agent_name and company are returned live but absent from the published schemas, while the documented application_url and scheduling_block did not appear in list responses. Polish problems compound it — an unmodified Docusaurus template placeholder page, a lone docs-blog post containing untranslated Russian, and the support knowledge base ShowMojo's own links point to is dead, returning HTTP 402 and rendering an "Account Canceled" page. Unanimous, with both graders noting the no band's "reverse-engineering is required" language is arguably met for the report family.
Reliable machine-consumable integration path
None of the three qualifying mechanisms exists. No published OpenAPI spec — six conventional paths probed, all 404; the rendered documentation was programmatically scanned for any download/spec/openapi/swagger/.json/.yaml/postman control, returning zero matches; the 591 KB main JavaScript bundle contained zero occurrences of securitySchemes and no "openapi":"3.x" declaration. No official SDKs in any language. No MCP server. The six-language samples are per-endpoint copy-paste snippets, not a consumable interface definition — they require exactly the manual transcription this check excludes. Unanimous.
AI-readable documentation
llms.txt and llms-full.txt return 404 on docs.showmojo.com, showmojo.com and hello.showmojo.com. No per-endpoint Markdown, no downloadable corpus, no equivalent format. Compounded by the contract being client-rendered only: the server-delivered HTML contains <div class="openapi-skeleton md"> placeholders where the parameter and schema tables belong, so fetching a documentation page returns prose without the API contract — precisely the retrieval pattern an AI coding tool uses. Unanimous.
Kept current
Monthly release notes run January through August 2026, current as of this assessment, and carry genuinely API-specific entries: "Listing Group Assignment Now Supported in Import API," "Vacancy Announcement Emails Now Sent for API-Imported Listings," "New Lead Trigger For Zapier Integration." That is real, regular, first-party change communication. But this check asks whether the reference is maintained as the API changes, and there is a direct counterexample: the very field that release note announces, listing_group_name, appears in live responses and was never added to the published response schema — it remains documented only as an import input. Compounding it, the page is product-wide marketing rather than an API changelog, the documentation site carries no changelog of its own (its blog holds one post from May 2025), and no deprecation guidance exists anywhere. Currency information exists but is demonstrably incomplete.
Category 5 · Access & Cost
15 / 15Self-serve API key
Credential creation is self-serve with no sales call, support ticket, or approval step evidenced. The documentation states the token "is available in the customer's Settings > Listing import section" and directs users to generate one at ShowMojo Plugins Settings; the knowledge base gives the direct URL, "generated at https://showmojo.com/settings/import." Corroborated two ways: the operator confirms they can generate a new token themselves, and a token obtained this way authenticated successfully against production on 2026-09-02. Unanimous.
Not commercially gated
API access is presented as a standard product capability, not a premium unlock. The pricing page itemizes every other add-on — AI Virtual Agent, Two-Way Prospect Messaging, lockbox and smart-lock hardware, per-device monthly fees — and never lists the API as a tier feature, add-on or line item. The public FAQ answers the question without qualification: "Yes, ShowMojo has a public API that supports programmatic listing management … Webhooks are also available." The terms condition API use on usage limits and acceptable use but impose no plan-tier requirement. All three sources that would naturally carry a gate were accessible and none does. Unanimous. Noted for transparency: no first-party source affirmatively enumerates API access as an included feature of the entry-level Pro plan; the mark rests on negative evidence across three sources that would each be expected to disclose a gate.
What works
- Self-serve token in settings, on any plan, with no API add-on or upsell
- Eight named bulk exports in JSON or CSV, with date filtering that works
- A webhook enumerating 120-plus lead and showing events, with a documented retry ladder
- Precisely typed listing schema that matched live responses field for field
- Public status page with uptime percentages and a real dated incident history
What to watch
- One all-powerful token: no read-only option, no scoping, no documented revocation
- No API endpoint confirms, cancels, reschedules or no-shows a showing
- No way to create or update a lead through the API
- Listings ignore page, per_page and every updated-since parameter tested
- Webhooks authenticate with a replayable static bearer token, not a signature
- No rate limit documented anywhere, and no rate-limit headers returned under load
- No OpenAPI spec, no SDK, no MCP server, and no AI-readable documentation
- The support knowledge base ShowMojo's own links point to is dead, returning HTTP 402
The bottom line for a property manager
ShowMojo's API is a one-way street, and you should plan around that. You can push your listings in and pull your leasing activity back out, leads, showings, no-shows, pre-screening answers, lockbox access and performance metrics, all date-filterable in JSON or CSV. What you cannot do is make ShowMojo act. There is no way to confirm, cancel or reschedule a showing through the API, and no way to create or update a lead, so the automations most operators actually want are not buildable today. What you can build is good reporting, a warehouse sync, and real-time reaction to leasing events, because the webhook coverage of showing and prospect activity is genuinely thorough and the export path works exactly as documented. Two limitations do most of the damage. Access control: one kind of key, not scopable, not read-only, able to overwrite your whole listing portfolio. And listing sync: no updated-since filter, no listing webhook, no pagination on the listings call, so noticing that a listing changed means re-pulling everything. Against that, the thing ShowMojo gets clearly right is access. No sales call, no upgrade, no approval, and that alone accounts for nearly two-thirds of the points it earned. Read the score for what it measures. This grades how buildable the API is for an operator, not whether the product does its job.
Check it yourself.
Both files behind this page, in full.
ShowMojo’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 ShowMojo 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.