Properties

A property is a building on the owner's roster. This endpoint creates and updates buildings. The same item shape is also accepted nested inside a prospect to create a building on the fly.

See the Onboarding overview for the array, result, and upsert conventions this endpoint shares.

Create or update properties

POST /partners/{owner_slug}/properties
Content-Type: application/json

[
  { "external_system_id": "acme-prop-123",
    "building_name": "The Hudson North",
    "address": {
      "line_one": "123 Main St Apt 4B",
      "city": "Brooklyn",
      "state": "New York",
      "zip": "11201",
      "line_two": null,
      "country": "US"
    },
    "type": "multifamily",
    "policy_holder_name": "Hudson Apartments LLC",
    "pms_type": "yardi",
    "pms_property_id": "gs-0041",
    "default_coverage": { "type": "multiplier", "value": 1.0 },
    "bank_account_external_id": "acme-bank-89",
    "active": true }
]

Request fields

Field	Required	Notes
`external_system_id`	yes	Your own identifier. The upsert key
`building_name`	yes	Part of the match key. Must be stable and distinct for each building
`address`	yes	Object, described below. An approximate seed: copy any one unit's address. Rhino normalizes it and later overwrites it with the street derived from the building's units. `line_two` and `country` are accepted and ignored
`type`	no	`single_family`, `garden_community`, `multifamily`, or `single_address_garden_community`. Defaults to `multifamily`. Send it only for single unit building kinds, where it controls how many units the building may hold
`policy_holder_name`	no	Legal entity on landlord policy documents. Defaults to `"<owner name>, LLC"`
`pms_type`	no	`yardi` or `realpage`, when the owner runs a PMS
`pms_property_id`	no	The PMS property code, when `pms_type` is present. For an owner with an existing Rhino relationship, send it: it is the primary match key
`default_coverage`	no	`{ "type": "multiplier", "value": 1.0 }`. Defaults to 1× monthly rent
`bank_account_external_id`	no	Claims payout account for this building (bank accounts). Defaults to the owner's default account. The account must already exist. An explicit `null` reverts to the default
`active`	no	Defaults to `true`. Send `false` to remove a building from the roster

The address object contains line_one, city, state, zip, and the ignored line_two and country. state may be a two letter abbreviation or the full name; ZIP+4 is accepted and truncated to five digits.

Response

{
  "status_code": 200,
  "results": [
    { "external_system_id": "acme-prop-123", "action": "created" },
    { "external_system_id": "acme-prop-124", "action": "updated" },
    { "external_system_id": "acme-prop-125", "action": "failed",
      "errors": { "building_name": ["several existing buildings match and nothing separates them"] } }
  ],
  "meta": { "created": 1, "updated": 1, "failed": 1 }
}

A failed item carries errors keyed by field; the other items still apply. A bank_account_external_id that Rhino does not recognize fails the item, so register the account first.

Property matching

On every item, in order:

Your stored identifier first. If external_system_id is already linked to a building, that building is updated and no further matching runs. Once a building is linked, renaming it or correcting its address is safe.
PMS pair, when the item carries one. An existing building under the owner with the same (pms_type, pms_property_id) is adopted, linked to your external_system_id, and updated. Because the codes come from the owner's own PMS on both sides, this match is exact and unaffected by address quality, which is why an owner with an existing Rhino relationship should always send the pair. One PMS property may map to several Rhino buildings, such as a garden community, in which case building_name selects among them.
Name and address. Owner, building_name, the normalized street line, and zip. Both sides are normalized, so unit designators are stripped and suffixes and directionals are canonicalized, and "123 Main St Apt 4B" matches a building stored as "123 Main Street". A street address alone does not identify a building; building_name is what separates buildings that share one.
Otherwise, create.

Where several candidates match and nothing separates them, the item fails and nothing is created. A building already linked to a different identifier also fails: one building, one identifier. That usually indicates the identifier changed on your side, which is a correction Rhino makes rather than an upsert.

Keep building designators such as Bldg 3 in building_name, not in the address. Unit designators are stripped by normalization; building designators are not, so a mismatch there fails visibly rather than merging two buildings.

Address derivation

The address you send is a starting estimate. As units load with their own addresses (units), Rhino derives the building's street as the portion shared across its units' cleaned addresses, so apartment numbers, floors, and occasional typos fall away. The derived value, presented in title case and expanded ("Main Street", not "MAIN ST"), is what appears on policies, so the stored property address may not exactly match what you sent.

Derivation stops writing once the address is corrected by Rhino staff, or once any policy exists against the building. After that, any disagreement between the roster and the stored address is logged rather than applied.

Removing a building

Send the property with active: false. New prospects stop resolving to it and no enrollment URLs are issued; existing policies are unaffected. Send active: true to restore it. This is the only way to remove a building from the roster: omitting it from a refresh does not remove it.

Owners with an existing Rhino relationship

Always send pms_type and pms_property_id. The PMS pair is the primary match key, so buildings Rhino already holds are adopted and linked to your identifiers rather than duplicated. A building outside the set Rhino has granted you fails the item, and Rhino resolves those on its side. See Owner types.

Renter Guarantee on creation

When the owner has guarantor_coverage_capable: true (see Property owners), a property created through this endpoint has Renter Guarantee enabled automatically, priced from default_coverage. This applies at creation only: it does not apply to an existing property matched by one of the rules above, even if the owner's flag was turned on after that property was created.

Next steps

Units: load a building's units so that its address and unit names resolve

Create or update properties​

Request fields​

Response​

Property matching​

Address derivation​

Removing a building​

Owners with an existing Rhino relationship​

Renter Guarantee on creation​

Next steps​