Rhino Developer Documentation
Documentation for integration partners offering Rhino's Security Deposit Alternative (SDA) to renters — whether you embed the purchase flow in your own product or hand off to Rhino.
Who this is for
Teams integrating Rhino into an existing renter-facing workflow:
- Leasing and application platforms
- Property management software
- Screening and renter services providers
How an integration fits together
Three pieces, in order:
1. Send Rhino a prospect. Preferably by emitting events from your own system in your own format, which Rhino subscribes to and maps onto its data model — see Partner Webhook Events. You can also push renters directly with the Partner Prospect API, or, if you cannot share renter data at all, have Rhino match renters against the property owner's PMS feed. Integration Types compares all three.
Either way, Rhino checks eligibility asynchronously and produces an enrollment URL scoped to that renter.
2. Send the renter to the enrollment flow. Either embedded in an iframe inside your product, or as a full-page redirect to Rhino. Rhino handles the application, underwriting, disclosures, payment, and policy issuance.
3. Stay in sync with webhooks. Rhino pushes signed events for the prospect, application, policy, and delinquency lifecycles. See the Webhooks Overview.
Embedded integrations also get browser-level postMessage events for immediate UI updates. Treat those as hints and webhooks as the source of truth — a browser can close before it reports anything.
What Rhino handles
Once the renter reaches the enrollment flow, Rhino owns the rest: identity and credit checks, state-specific disclosures, FCRA adverse-action notices, payment collection, and policy documents. Your integration never touches payment details.
Terms you will hear
Rhino uses some of these interchangeably in conversation, and a few are abbreviated heavily in email:
| Term | Meaning |
|---|---|
| SDA | Security Deposit Alternative, the product a renter buys instead of paying a cash deposit. Occasionally written SDI, for the underlying security deposit insurance. |
| Cash deposit | The traditional deposit, which Rhino can also collect and hold. It appears alongside SDA as a second product a renter may be offered. |
| Prospect | The renter record you create in Rhino, before any policy exists. Also called a third-party prospect or 3PP — "third-party" because the data came from you rather than from a property management system. |
| Property owner | Rhino's client — the operator whose renters you are serving. Identified by a slug used in Partner API paths. You may work with several. |
| Source | Your partner code, assigned by Rhino. Combined with your own source_prospect_id, it identifies a renter across every call and event. |
| Embedded / expedited | The two purchase flows. Embedded renders in an iframe in your product; expedited is hosted by Rhino full-page. Despite the name, expedited is not a shorter application. |
| EPF | Embedded Purchase Flow, Rhino's internal name for this integration program as a whole. |
| PMS | Property management system, such as Yardi or RealPage. Where a property owner's residents and units live. |
| Coverage amount | What the SDA covers, derived from the property owner's rules rather than from the deposit figure you send. |
After the policy is issued
Your integration's job ends at issuance, but the policy keeps changing and those changes reach you as webhooks.
Property managers service policies in Rhino's Portal — cancellations, coverage or rent corrections, and moves to a different unit. Renters contact Rhino directly for anything about their own policy. Neither path runs through you.
What it means for your integration is that a policy you have already recorded can be revised later. A successful change produces a new document archive, so if you store or display policy documents, refresh them on policy.documents_updated rather than treating the copy you fetched at purchase as final.
Getting help
Before escalating, most integration problems are visible to you directly. Check the delivery history for the exact payload Rhino sent and why an attempt failed, and check your browser console for CSP and origin errors on embedded flows.
When you do need Rhino, include your source and source_prospect_id, the property's integration code, a timestamp, and the X-Webhook-Delivery ID if a webhook is involved. Those five things are what a Rhino engineer needs to find the record.
Questions, credentials, and domain allowlisting all go through your Partner Success Manager.
Where to start
- Quick Start Guide — one end-to-end enrollment on staging
- Authentication & Environments — credentials, base URLs, and slugs
- Integration Types — choosing between the available patterns