Greenlight Rent Developer Documentation
Documentation for integration partners offering Greenlight Rent products to renters — Greenlight Deposit, a security deposit alternative, and Greenlight Guarantee, a guarantor alternative — whether you embed the purchase flow in your own product or hand off to Greenlight.
These products were formerly Security Deposit Alternative (SDA) and Renter Guarantee (RG). API fields and enum values keep those names, such as sdi_ineligibility_reasons, rg_eligibility_status, and renter_guarantee_insurance.
Who this is for
Teams integrating Greenlight 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 Greenlight a prospect. Preferably by emitting events from your own system in your own format, which Greenlight 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 Greenlight match renters against the property owner's PMS feed. Integration Types compares all three.
Either way, Greenlight 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 Greenlight. Greenlight handles the application, underwriting, disclosures, payment, and policy issuance.
3. Stay in sync with webhooks. Greenlight 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 Greenlight handles
Once the renter reaches the enrollment flow, Greenlight 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
Greenlight uses some of these interchangeably in conversation, and a few are abbreviated heavily in email:
| Term | Meaning |
|---|---|
| Greenlight Deposit | Greenlight Deposit, the product a renter buys instead of paying a cash deposit. Occasionally written SDI, for the underlying security deposit insurance. |
| Greenlight Guarantee | Lease / guarantor coverage for renters who need a guarantee rather than a deposit alternative. Distinct from Greenlight Deposit. Partners select it on a prospect with guarantor_coverage: true. |
| Cash deposit | The traditional deposit, which Greenlight can also collect and hold. It appears alongside Greenlight Deposit as a second product a renter may be offered. |
| Prospect | The renter record you create in Greenlight, 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 | Greenlight'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 Greenlight. 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 Greenlight full-page. Despite the name, expedited is not a shorter application. |
| EPF | Embedded Purchase Flow, Greenlight'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 a policy will pay, derived from the property owner's rules. For Greenlight Deposit that is typically not the cash-deposit figure you send. For Greenlight Guarantee it comes from Greenlight's guarantor application rules and rent, not deposit_amount_cents. |
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 Greenlight's Portal — cancellations, coverage or rent corrections, and moves to a different unit. Renters contact Greenlight 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 Greenlight sent and why an attempt failed, and check your browser console for CSP and origin errors on embedded flows.
When you do need Greenlight, 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 Greenlight 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