Integration Types Overview

An integration has two parts: how renter data reaches Rhino, and how the renter completes their purchase. This page covers the options for each and how they combine.

Data transfer

Partner webhook events (preferred)

You emit events from your own system in your own payload format, and Rhino subscribes to them. Rhino writes and maintains the mapping from your schema onto its prospect model.

This is Rhino's preferred path. Nothing on the sending side is Rhino-specific: if your platform already emits an event when a prospect is created or updated, you point that stream at Rhino rather than writing a client. There is no property owner slug to manage — Rhino resolves the owner from the PMS property identifier already in your payload — and no synchronous call sitting in your critical path. The purchase flow and the webhook receiver are still yours to build.

1. You emit an event when something changes on your side
2. Rhino queues it, normalizes it, and creates or updates the prospect
3. Rhino emits prospect.ready with an enrollment_url
4. You send the renter to the enrollment URL

Use it when your platform is already event-driven, or when you would rather not maintain integration code against Rhino's API.

The tradeoff is onboarding: Rhino writes the adapter for your schema before events start landing, so going live is collaborative rather than self-serve. Ingestion is also one-way, so problems with an individual event surface in Rhino's logs rather than as an error you can catch.

See the Partner Webhook Events reference.

Partner Prospect API

You POST what you know about the renter to Rhino and get the prospect back synchronously, including validation errors.

Choose this when you want to be integrated without waiting on Rhino to build an adapter, when you want malformed or missing data reported back to you as a 422 at the moment you send it rather than discovered later, or when you want to read prospect state on demand rather than reacting to events.

1. POST /partners/{owner_slug}/prospects with the renter's details
2. Rhino validates the request synchronously and returns the prospect
3. Rhino runs eligibility in the background and emits prospect.ready with an enrollment_url
4. You send the renter to the enrollment URL

The two paths write to the same prospect record, keyed on (source, source_prospect_id), so they combine freely. Even on a webhook-first integration the API's GET endpoint is useful for reading a prospect's current state.

See the Partner Prospect API reference.

Shared PMS data

When you and Rhino both work with the same property management company, the property owner's PMS feed (Yardi or RealPage) supplies resident data to Rhino independently. Neither side shares renter data with the other.

In this model you link or frame Rhino's enrollment entry point and the renter identifies themselves by email. Rhino matches that email against the resident records it already syncs from the PMS and prefills from there.

https://www.sayrhino.com/enrollment/{property_owner_slug}/preapplication
https://www.sayrhino.com/enrollment/embedded/{property_owner_slug}/preapplication

The second form is the iframe variant. Both accept email and property_id to skip the lookup step, and ref to attribute the referral to you — ref is stored in a cookie for 30 days, so attribution survives the renter leaving and coming back.

Use this when you cannot send renter data to Rhino for privacy or contractual reasons, or when the property owner owns the resident relationship. The tradeoff is that Rhino has no prospect record tied to your identifiers, so you get no per-renter webhooks and no tracking beyond the referral cookie.

Purchase flow

Both purchase flows run the same application, underwriting, and payment steps. They differ only in whether Rhino renders inside your page or takes over the browser.

Note that pricing is produced here, not upstream. Underwriting needs a few data points that Rhino collects from the renter during enrollment, so a ready prospect has an enrollment URL but no premiums attached to it yet. You cannot quote Rhino in your own UI before the renter visits.

Which one applies is a property of your partner source, configured by Rhino. You do not choose per renter — the enrollment_url Rhino returns already points at the right flow. To switch, talk to your Partner Success Manager.

Embedded

https://www.sayrhino.com/enrollment/embedded/{property_owner_slug}/{source}/{source_prospect_id}?email=...

Rhino renders in an iframe in your application. The renter never leaves your product, and the flow signals its outcome back to your page via postMessage.

Requires Rhino to allowlist your domain for framing and to know which origin to post events to. See Embedded SDA Flow.

Choose this when you want visual continuity and can accommodate an iframe with roughly 800px of height.

Expedited

https://www.sayrhino.com/enrollment/expedited/{property_owner_slug}/{source}/{source_prospect_id}?email=...

Rhino hosts the flow full-page. You redirect the renter and Rhino sends them back to a redirect_url you supply, provided its host matches the domain Rhino has allowlisted for your source. Ask your Partner Success Manager to register that domain before you rely on the parameter — an unrecognized host is ignored rather than rejected.

There is no postMessage and no framing configuration. Despite the name, the steps are the same as the embedded flow — "expedited" refers to the hosted delivery, not a shorter application.

Choose this when you cannot host an iframe, are working in a constrained mobile viewport, or want the simplest possible integration.

Putting them together

Pattern	Data transfer	Purchase flow	Why
Recommended	Partner webhook events	Embedded	Least integration code on your side, renter stays in your product
Event-driven, no iframe	Partner webhook events	Expedited	Same ingestion with a simpler front end
Self-serve	Prospect API	Embedded or expedited	Go live without waiting on a Rhino-built adapter, with synchronous validation
No data sharing	Shared PMS data	Embedded or expedited	Works when you cannot send renter data, at the cost of prefill and tracking

In every case, subscribe to Rhino's outbound webhooks for authoritative outcomes. The renter's browser is not a reliable reporter of what happened, and on the event-driven paths it is the only way to learn the enrollment URL.

Security expectations

• All traffic is HTTPS. Rhino rejects plaintext HTTP for API calls and webhook destinations.
• Renter PII belongs in request bodies, never in query strings or path segments.
• Verify every webhook signature before acting on the payload.
• Validate event.origin on every postMessage you receive.
• Rhino handles payment collection and card data end to end. Your integration never touches payment details, and nothing in this integration brings you into PCI scope.

Next steps

1. Check your data against Prospect Data Requirements
2. Read Partner Webhook Events and send Rhino sample events to start onboarding
3. Walk through the Quick Start Guide
4. Read Authentication & Environments if you are also calling the API