Rentiful Open Data

How it works

Rentiful makes your rental inventory discoverable to AI agents, search engines, and developers — without exposing sensitive business data.

Three layers serve different audiences:

• This page — the public data specification for operators and industry
• rentiful.md — documentation for AI agents (ChatGPT, Claude, etc.)
• rod.rentiful.ai — the API for developers building rental tools

Why this exists

Rental data is usually designed for accounting systems, not for people.

Most public rental datasets leak internal legal structures, ownership models, CRM artefacts and database keys. That might work for back-office workflows, but it creates friction for renters, search engines and AI systems trying to understand what actually exists in the real world.

At Rentiful, we believe rental data should be treated as a product, not a spreadsheet.

Design principles

• Renter-native: uses concepts renters recognise, not internal legal or operational abstractions.
• Stable by default: public identifiers should not change just because internal systems or vendors do.
• Decoupled from ownership and leasing: who owns a home or how it is financed is intentionally out of scope.
• Machine-consumable: designed for APIs, search engines and AI agents, not just human readers.
• Works for BTR and SFH: the same model must scale from single-family neighbourhoods to complex, multi-building BTR schemes.

The public ontology (v1)

The v1 public model consists of six entities:

Place (p_xxx)           ← Neighbourhood or destination
  │
  ├── Collection (c_xxx) ← Named cluster (optional)
  │     │
  │     └── Building (b_xxx) ← Physical structure
  │           │
  │           └── Unit (u_xxx) ← Rentable home
  │                 │
  │                 └── Listing ← Available unit with price
  │
  └── Building (b_xxx)   ← Can belong directly to Place
        │
        └── Unit (u_xxx)
              │
              └── Listing

Operator (o_xxx)        ← Managing brand (linked to Buildings)

• Place: a neighbourhood or destination renters recognise (e.g. Wembley Park, East Village).
• Collection: a named cluster within a Place (e.g. Ferrum, Portlands Place).
• Building: the physical structure people say they live in (e.g. Sky Point, Landsby East).
• Unit: an individual rentable home.
• Listing: a Unit that is currently available, with price, availability date, and images. This is what renters see. Uses the Unit ID (u_xxx).
• Operator: the current managing brand.

Single-Family Homes (SFH)

For Single-Family Homes, this model collapses naturally:

• Place = neighbourhood
• Building = the house
• Unit = the home

What this contract excludes

To keep the public boundary clean, the following are explicitly not exposed:

• Lease and tenancy information
• Ownership or portfolio structures
• Vendor or feed identifiers
• Emails and phone numbers

Public IDs

Each entity is assigned a stable, opaque public ID:

• IDs are generated once, at first discovery
• IDs persist forever
• IDs do not expose internal database keys or vendor identifiers

Schemas and API

Machine-readable schemas and API access are available at:

• JSON Schemas (HTML index)
• OpenAPI specification
• ROD API documentation

Versioning

This contract is versioned. The current version is v1.

• Non-breaking additions may occur within v1
• Breaking changes will result in v2

Open collaboration

If you work in Build-to-Rent, Single-Family rental portfolios, PropTech platforms, or AI, we would value thoughtful critique and collaboration.

Discussion is happening publicly on LinkedIn: Rentiful on LinkedIn.