Integrating with Resi: a guide for PMS and CRM providers

This document is for engineering and partnership teams at property management systems (PMS) and lead management / CRM platforms who are integrating with Resi.

It describes what Resi needs from your API, what we do with the data, and how the integration is built, tested, and supported. It does not require any knowledge of Resi's internals — Resi builds and maintains the connector. Your side of the work is providing an API, sandbox access, documentation, and a technical contact.

---

1. How the partnership worksCopy Anchor Link

Resi is a property marketing and leasing platform. Property management companies use it to run their community websites, listings, pricing display, and lead capture. Resi is not a system of record — it reflects what lives in the operator's PMS, and it hands prospects off to the operator's CRM.

A connection is the integration between Resi and one external service, configured per operator account and linked to individual properties. Once your integration exists, any Resi customer who uses your platform can enable it themselves: they pick your product from a catalog, enter their own credentials, and map each of their properties to its counterpart in your system.

Who does whatCopy Anchor Link

Two integration directionsCopy Anchor Link

Most partnerships are one or the other; some are both. If you offer both a PMS and a CRM product, they are built as two separate connections, because operators frequently pair one vendor's PMS with another vendor's CRM.

---

2. Requirements for any integrationCopy Anchor Link

Access and authenticationCopy Anchor Link

• A sandbox or test environment with credentials we can use throughout the build, populated with realistic data (see Testing for what "realistic" means).
• A documented authentication scheme. We support the common patterns: API key headers, HTTP basic auth, bearer tokens, OAuth 2.0 client credentials, and SOAP with WS-Security. Tell us which, and whether tokens expire — if they do, we implement refresh-and-retry, but we need the refresh flow documented.
• Clarity on credential scope. State explicitly which credentials apply to an entire management company account and which are specific to a single property. This determines how the setup form is structured for operators, and getting it wrong is the single most common cause of a failed customer onboarding.
• HTTPS with a valid, publicly trusted certificate. We do not disable TLS verification.

DocumentationCopy Anchor Link

• Endpoint reference with request and response schemas.
• At least one realistic sample response per endpoint — ideally a real (anonymized) payload rather than a minimal illustrative one. Optional fields that are always populated in practice, and fields that are frequently null, are both things we can only learn from real data.
• Enumerated values and their meanings (unit statuses, amenity categories, lead source codes).
• Date, time, and timezone conventions. Please state whether dates are local to the property or UTC — ambiguity here produces availability bugs that surface weeks later.
• Error response format and the HTTP status codes you use.

Operational characteristicsCopy Anchor Link

• Rate limits, and what happens when they are exceeded (429 with Retry-After, or something else). Resi syncs many properties per account; we will pace requests, but we need the numbers.
• Pagination, if any endpoint can return more rows than a single response holds.
• Expected response times and any endpoints known to be slow.
• Change management: how you version your API, how much notice you give before breaking changes, and how we subscribe to those notices.
• A named technical contact for the build, and a support channel for production issues after launch.

What we will not ask you forCopy Anchor Link

Resi does not require you to build anything Resi-specific. We consume standard, documented APIs. If you already have a public partner API, that is usually enough.

---

3. PMS integrations — data into ResiCopy Anchor Link

What we do with the dataCopy Anchor Link

Resi pulls your data on a schedule and mirrors it into its own property, floor plan, and unit records, which then drive the operator's website: listing pages, floor plan detail pages, availability, and displayed pricing.

Two properties of this process are worth understanding, because they shape what we need:

• Syncs are repeated and incremental. The same import runs every few hours, indefinitely. We match records on your identifiers and update in place. We never wipe and reload.
• Operators can turn individual fields off. A customer who maintains better marketing copy in Resi can disable Unit Description for their connection, and our sync will leave it alone. This means partial data from you is workable — we would rather import ten reliable fields than twenty unreliable ones.

Identifiers — the most important requirementCopy Anchor Link

Every record you return must carry a stable, unique identifier that does not change over the life of the record. We store it and use it to match on every subsequent sync.

If a unit's identifier changes, Resi treats it as a new unit and the old one becomes stale. Identifiers that are actually derived values — a unit number, a name, a composite of building and unit — will eventually collide or change, and cause duplicate or orphaned records.

We need identifiers for: properties, buildings (if modeled), floor plans / unit types, units, and amenities.

Endpoints we look forCopy Anchor Link

A single endpoint returning several of these is fine. So is one endpoint per record type. What matters is that each is filterable by property.

Fields Resi can storeCopy Anchor Link

You do not need to supply all of these. This is the full surface — send what you have.

Floor plan

Building — name, number, code. Only relevant for multi-building communities.

Unit

Property — name, description, website, application link, tour link, resident portal link, email, phone, address, pet policy, office hours, images, community amenities, staff, lead sources.

Availability semanticsCopy Anchor Link

Tell us precisely what "available" means in your data. The distinction that matters:

• Is a unit available when it is physically vacant, or when it is vacant and unleased?
• Do you expose notice-given units (occupied, but with a known future vacate date)?
• Does your units endpoint return only available units, or all units with a status field?

This last point matters operationally: if your endpoint returns only currently-available units, we mark everything absent from the response as unavailable. If it returns all units with a status, we read the status instead. Both work — we just have to know which.

Pricing semanticsCopy Anchor Link

Two questions, both of which change what a prospect sees on the website:

1. Is the rent you return base rent, or does it already include mandatory fees? Resi models fees separately and can display base rent, an all-in total, or both. If your figure is already all-in and we treat it as base, mandatory fees get added twice.
2. Is it market rent, asking rent, or effective rent (net of concessions)? If you expose more than one, tell us which fields carry which, and we will let operators choose.

If you support term-based pricing (rent varying by lease length and move-in date), describe the shape of that data. Resi can store and display a full price matrix.

Application deep linksCopy Anchor Link

If a prospect can go straight from a listing into your application flow, tell us how to construct that URL — including any unit, lease term, or move-in date parameters. This measurably improves conversion for the shared customer and is one of the highest-value optional pieces.

---

4. CRM integrations — leads out of ResiCopy Anchor Link

What triggers a sendCopy Anchor Link

A prospect submits a form on a Resi-powered property website — a contact form, a tour request, a "check availability" inquiry. Resi stores the lead, then delivers it to every CRM connection the operator has enabled for that form and that property. Delivery is immediate, once per lead, per connection.

Operators choose which forms route to which CRM, so one property can send tour requests to one system and general inquiries to another.

Delivery optionsCopy Anchor Link

Option A — REST API (preferred). You expose an endpoint that accepts a lead. We post to it and check the response. This gives real confirmation of receipt and lets us surface failures to the operator.

Option B — email parser. You provide a monitored inbox address per property, and we send a formatted email. This works and several of our integrations use it, but it is strictly worse: we cannot confirm the lead was parsed, formatting is brittle, and diagnosing a miss means asking you to check logs. If you offer both, we will build against the API.

If we do build an email integration, we need a real sample email that your parser accepts. We match the format exactly — field labels, order, and wording — because parsers are unforgiving of variation.

The lead payloadCopy Anchor Link

These are the fields Resi can send. Which are actually present depends on how the operator built their form, so treat everything except email as optional in your validation.

Tell us your required fields and their formats, and whether you have a separate endpoint or payload shape for tour appointments as distinct from general inquiries.

Lead source attributionCopy Anchor Link

Resi tracks where a prospect came from (paid search, a listing site, an email campaign) and can pass that through. If your system has its own lead source taxonomy — codes, IDs, or a fixed vocabulary — tell us how to obtain the valid values. If you expose them via API, we can present them as a dropdown during setup so operators pick a valid source rather than typing a string that silently fails validation on your side.

Response and error handlingCopy Anchor Link

• Return a clear success or failure status. A non-2xx response is treated as a failure, logged against the property, and surfaced on the operator's Connection Issues dashboard.
• Do not return 200 for a rejected lead. If validation fails, say so with a status code and a message. A silent rejection becomes a lead the operator believes was delivered.
• Include a reason in error responses. "Invalid property ID" resolves in minutes; "Bad Request" becomes a support ticket.
• Tell us whether your endpoint is idempotent, and whether retrying a lead risks a duplicate.

ThroughputCopy Anchor Link

Lead volume is bursty — a listing promotion or a paid campaign can produce a spike. Tell us your per-minute limits so we can pace accordingly.

---

5. Testing and certificationCopy Anchor Link

What we need in the sandboxCopy Anchor Link

A sandbox that only contains one clean property will pass tests and then fail in production. We ask for test data that includes the messy cases:

• At least one multi-building property and one single-building property.
• Floor plans with multiple units, including some available and some not.
• At least one unit with no availability date, and one available in the future.
• Null and empty optional fields — the real-world state, not the ideal one.
• Amenities at both community and unit level.
• Images at property, floor plan, and unit level.
• Where applicable: concessions/specials, term-based pricing, and affordable or accessible units.

For CRM: a sandbox endpoint or inbox that we can post to repeatedly, and a way to verify what arrived.

What Resi verifies before launchCopy Anchor Link

• A full sync completes end to end and produces correct floor plans, units, availability, and pricing.
• Re-running the sync updates records rather than duplicating them.
• Units removed from your feed correctly become unavailable.
• Fields the operator has disabled are not overwritten.
• Authentication failures, timeouts, and malformed responses produce clear logged errors rather than silent partial data.
• For CRM: leads arrive with correct field mapping, and rejected leads surface as errors.

We will share the results with you, including any data-quality issues we find in the sandbox — these are often the most useful output of the process for both sides.

PilotCopy Anchor Link

Before general availability we run the integration on one or two real properties with a willing shared customer, typically for two to four weeks. This catches production-scale issues that no sandbox reproduces: real rate limits, real data volumes, and the long tail of unusual records.

---

6. Launch and ongoing supportCopy Anchor Link

Going liveCopy Anchor Link

Once certified, your integration appears in Resi's connection catalog and becomes self-service. Any shared customer can enable it, enter their own credentials, and map their properties without involving either of our teams — provided they can obtain API access from you. If access requires provisioning or approval on your side, tell us the process and we will document it in the setup instructions so customers are not stuck.

MonitoringCopy Anchor Link

Resi logs every sync and every lead delivery, with duration, status, and error detail, and surfaces failures to operators on a dedicated dashboard. If we see a pattern of errors originating from your platform, we will raise it with your support contact rather than leaving the customer between us.

Changes to your APICopy Anchor Link

Please give advance notice of:

• Breaking schema changes, removed fields, or changed enumerated values.
• Endpoint deprecations and sunset dates.
• Authentication changes.
• New capabilities we could adopt — new fields, a pricing matrix endpoint, a lead source API.

We would rather update a connector on your schedule than discover a change through a customer's failed sync.

---

Appendix A — Integration questionnaireCopy Anchor Link

Returning this before kickoff removes most of the back-and-forth. Every question maps to a decision we have to make in the build.

General

1. Product name(s) and whether you are integrating as a PMS, a CRM, or both.
2. Authentication scheme, and whether credentials are per-account or per-property.
3. Sandbox URL and credentials.
4. Link to API documentation.
5. Rate limits and pagination scheme.
6. API versioning and deprecation policy.
7. Technical contact for the build; support channel for production.
8. Any provisioning or approval step a shared customer must complete to get API access.

PMS

9. Endpoints available for: property list, property detail, floor plans/unit types, units, amenities, images, pricing matrix.
10. The stable identifier for each record type.
11. Does the units endpoint return all units with a status, or only available ones?
12. What exactly does "available" mean in your data? Are notice-given units included?
13. Is the rent value base rent or inclusive of mandatory fees?
14. Is it market, asking, or effective rent? Are multiple values available?
15. Do you support term-based pricing? What shape is that data?
16. Date and timezone conventions.
17. Can we construct a deep link into your application flow? What parameters does it take?

CRM

18. REST API, email parser, or both?
19. Endpoint(s), required fields, and formats.
20. Separate handling for tour appointments?
21. Lead source taxonomy — fixed values, or retrievable via API?
22. Error response format and status codes.
23. Idempotency and duplicate behavior on retry.
24. Per-minute throughput limits.
25. For email delivery: a real sample email your parser accepts.

---

Appendix B — GlossaryCopy Anchor Link