Building a custom connection
What it takes to connect a system Resi does not support yet: what we build, what we need from you, and what sizes the job.
A plain-language overview for Resi customers who want their own system connected to Resi.
If you use a platform Resi already supports, none of this applies — you can enable it yourself in minutes from the Connections page. This document is for the case where the system you use is not in our catalog and you are asking what it would take to add it.
It explains what we build, what we need from you, what drives the size of the job, and what happens after launch.
What a connection actually does
Resi powers your property websites: your listings, floor plans, availability, pricing, and the forms prospects fill in. But Resi is not where your data lives. Your PMS is. And when a prospect inquires, that lead needs to land in whatever system your leasing team actually works in.
A connection is the bridge. There are two kinds, and they run in opposite directions.
A PMS connection brings data in. Every few hours, Resi asks your property management system what's changed — which units are available, what they rent for, when they're ready — and updates your website automatically. Your team keeps working in the PMS exactly as they do today. Nobody maintains a second copy of anything.
A CRM connection sends leads out. The moment someone submits a form on your site, that inquiry is delivered into your leasing CRM, with the prospect's details, their message, their desired move-in date, and where they came from. Your leasing team works their normal queue.
Most customers need one of each. They're built and configured separately, because it's very common to run one vendor's PMS alongside a different vendor's CRM.
What we build
The connection is a piece of software we write, test, and then maintain as part of the Resi platform. Here's what actually goes into it, in the order it happens.
1. Discovery
We work with you and your software vendor to answer a set of specific questions: Does the system have an API? How does it authenticate? What data does it expose, and in what shape? What does "available" mean in their data — physically vacant, or vacant and unleased? Does the rent figure include mandatory fees, or is it base rent?
That last pair of questions sounds like a detail. It isn't. Get them wrong and your website shows the wrong availability or the wrong price, and neither error is obvious until a prospect calls about it. Most of discovery is eliminating that class of ambiguity before any code is written.
We need from you: an introduction to your vendor's technical contact, and your authority for them to talk to us. We need from them: API documentation, test credentials, and sample data.
This phase is where projects stall. Not because the work is hard, but because vendor responsiveness varies enormously — and we cannot proceed without their cooperation.
2. Build
We write the connector: the piece that authenticates against your system, requests the data, translates their model into Resi's, and handles everything that goes wrong along the way — expired credentials, timeouts, a property that returns no units, a field that's null for half the records.
Translation is the substantial part. Every system models a property differently. One calls it a unit type, another a floor plan, another a plan code. One reports square footage per unit, another only per plan. One returns only available units; another returns everything with a status attached. Fitting a vendor's model onto Resi's, field by field, is most of the engineering.
We also build your setup screens: where credentials get entered, and where each of your properties gets mapped to its counterpart in the other system.
3. Testing
We test against your vendor's sandbox, and specifically against the awkward cases: a multi-building community, a unit with no availability date, records with empty optional fields, a property with concessions. We verify that running the sync repeatedly updates your data rather than duplicating it, that units removed from the feed correctly show as unavailable, and that a failure is reported clearly rather than quietly leaving your site half-updated.
We also verify that anything you maintain by hand in Resi — better marketing copy, a curated photo order — is preserved, because you can switch off individual fields per connection and the sync will leave those alone.
4. Pilot
We turn the connection on for one or two of your properties and watch it for a few weeks. Sandboxes never contain the full weirdness of real data, and this is where the last issues surface. We ask your team to sanity-check what's appearing on those sites during this period.
5. Rollout
Once the pilot is clean, we enable the remaining properties. From then on the sync runs on a schedule you control, with a full log of every run and a dashboard showing any errors.
What determines how big the job is
Custom connections vary enormously in effort, and almost all of the variation comes from the system on the other side, not from Resi. These are the factors that move the number, roughly in order of impact.
| Factor | Smaller job | Larger job |
|---|---|---|
| Does an API exist? | Documented, public API | No API, or a file export / manual process |
| Documentation quality | Complete reference with real examples | Sparse or out-of-date docs, learned by trial |
| Vendor responsiveness | Named contact, quick answers | Slow or reluctant vendor |
| Data completeness | Everything Resi displays is available | Gaps requiring manual maintenance in Resi |
| Data model fit | Concepts map cleanly to floor plans and units | Unusual model needing significant translation |
| Pricing complexity | Single rent figure per unit | Term-based pricing, concessions, fee-inclusive rents |
| Authentication | API key or basic auth | OAuth with refresh, or per-property credential provisioning |
| Scope | Leads only (CRM) | Full inventory, pricing, images, amenities (PMS) |
Some rough shape, to set expectations — these are indicative bands based on comparable integrations, and we confirm a real estimate after discovery:
| Scenario | Typical effort |
|---|---|
| CRM delivery by email parser | Days |
| CRM delivery by a documented API | 1–2 weeks |
| PMS with a clean, documented API and standard data model | 4–8 weeks |
| PMS with gaps, an unusual model, or a slow vendor | Longer — driven mostly by discovery and vendor turnaround |
| System with no API at all | Not viable as a connection until an API exists |
Elapsed time is usually longer than effort, because it includes waiting on the vendor and the pilot period.
The hard blocker
If your system has no API, we cannot build a connection to it. There is no workaround worth having. Nightly file drops and screen-scraping both look like solutions and both fail in ways that are expensive and hard to diagnose — a format change nobody told us about, a scrape that silently returns nothing, and your website quietly showing month-old availability.
If you're in that position, the productive move is a conversation with your vendor about their API roadmap, which we're glad to join. It's also worth knowing that a request from a paying customer carries considerably more weight with a vendor than a request from us.
What we need from you
Not much, but the few things matter:
- An introduction to your vendor's technical team, and your authority for us to work with them directly. This is the single biggest determinant of how fast this goes.
- Test credentials, which usually have to be requested by you as the account holder rather than by us.
- Clarity on how your team actually works. Which fields do you maintain by hand in Resi today and want left alone? Which properties should pilot? Does your rent figure include fees?
- Someone to sanity-check the pilot — a leasing or marketing person who knows what those properties' availability and pricing should look like, and will notice if it's wrong.
After launch
The connection becomes part of the Resi platform and we maintain it. That includes monitoring sync health, investigating failures, and updating the connector when your vendor changes their API.
Two things to expect over time:
- Vendor API changes. These happen. Well-run vendors give notice; others don't, and we find out from a failed sync. We monitor for this and fix it.
- Scope growth. It's common to launch with inventory and pricing, then add images, amenities, or application deep links once the core is stable. Starting narrow and extending is usually faster than trying to build everything at once.
You'll have a Connection Issues dashboard showing any errors across all your connections, and a full log for each sync — so you can see for yourself whether last night's update ran, and what it did.
Common questions
Will this integration be exclusive to us? Not usually, and that's to your advantage. Once built, the connection becomes a standard part of Resi. Other customers on the same platform can use it, which means it gets more real-world exercise and stays better maintained than something used by one account.
Do we have to change how our team works in the PMS? No. The connection reads what's already there. Your team keeps working exactly as they do today. The one thing worth knowing is that data quality in your PMS now shows up on your website — if a unit's availability date is wrong in the PMS, it'll be wrong on the site.
What if we only want leads, not inventory? That's a CRM connection on its own, and it's a much smaller piece of work. Plenty of customers start there.
Can we still edit things in Resi once the sync is running? Yes, and this is a real feature rather than a caveat. Any field can be excluded from the sync per connection, so if you write better floor plan descriptions in Resi than exist in your PMS, you turn that field off and it's never overwritten.
What if we're switching PMS next year? Worth telling us early. It may make more sense to build against the new system, or to sequence the work around the migration rather than building twice.
How do we start? Talk to your Resi contact with the name of the system and, if you have it, a link to its API documentation. We can usually tell you within a few days whether it's straightforward, complex, or blocked — and if it's blocked on a missing API, exactly what to ask your vendor for.
If your vendor's engineering team wants the technical detail, send them Integrating with Resi: a guide for PMS and CRM providers. It covers exactly what Resi needs from an API.
Last updated on