That single fact decides your whole integration design. Listing, Property and Inquiry are packaged Salesforce objects, so you address them through the Salesforce APIs — REST, Bulk, Pub/Sub, platform events — under Salesforce's auth model and Salesforce's limits. Twopir Consulting designs and builds against that surface, plus the RESO Web API feeds on the MLS side. Written for the people who have to make it not break at three in the morning.
Trusted by 500+ organizations — including brokerages, property managers and real estate investment groups whose MLS feeds, portal endpoints and event-driven integrations Twopir Consulting designs, builds and instruments.
What We Build Against
Every one of these passes a demo. They surface in month three, when the nightly feed doubles, the MLS reissues an identifier, or a retry storm meets a governor limit. Integration design is failure design.
The integration creates records rather than upserting against an external ID. Then a message is redelivered, a job is re-run after a timeout, or a feed resends yesterday's page — and the same listing exists twice with different statuses. Idempotency is a design decision, not a library.
A REST call per record works beautifully at ten records and falls over at ten thousand. Salesforce enforces caps on API volume, on callouts within a transaction and on concurrent long-running requests, and an integration that ignores them fails first at the worst possible moment.
Bulk and composite operations return per-record results, and a job can complete with a subset failed. Integrations that check only the job status report a clean run while forty records silently never landed — usually the ones with the unusual data.
A password, a security token or a hard-coded session in a script somebody wrote two roles ago. It works until a policy change or a rotation, and then the feed stops with no owner and no alert. Named credentials and a proper OAuth flow exist precisely to remove this class of outage.
A transient error triggers an immediate retry, which fails, which retries. The integration turns one bad minute into an exhausted daily API allocation, and every other integration in the org goes down with it. Backoff, jitter and a dead-letter queue are not optional at volume.
Propertybase objects and fields carry the managed package's namespace prefix. Integrations written against unprefixed API names work in one sandbox and break in another, and code that assumes a field name will survive a package upgrade eventually finds out that it will not.
Propertybase Salesforce Edition is a managed package installed into your own Salesforce org, so it exposes no separate API of its own. Listing, Property, Inquiry and the transaction records are Salesforce objects that happen to carry the package's namespace prefix, and you reach them through the platform's own interfaces: REST and Composite for synchronous work, Bulk for volume, and Pub/Sub with platform events and Change Data Capture for streaming. Authentication is Salesforce authentication — a connected app and an OAuth flow, with named credentials holding the secrets. So are the limits.
On the MLS side the picture is different and moving. The industry standard is now the RESO Web API, an OData-based interface built on the RESO Data Dictionary, which replaced the older RETS feeds most legacy integrations were written against. Propertybase ships its own MLS, IDX and portal synchronisation on top of that layer, and vendor documentation for the portal feed, field mapping and syndication lives at help.propertybase.com. One vendor requirement is load-bearing for every listing integration: each listing needs a unique, never-changing identifier — a broker listing ID or MLS ID — and that field is what your upserts key against.
Who this is for: developers, integration architects and technology leaders building against a Propertybase org. If you are deciding which business systems should connect and who owns each flow, the commercial view is on Propertybase integration instead. We help growing and mid-market companies solve complex CRM, integration, and business system challenges, and we work with enterprise organizations facing the same problems at greater scale.
Choosing the right Salesforce interface for a Propertybase integration
| REST & Composite | Bulk | Pub/Sub, platform events & CDC | Apex callout & External Services | |
|---|---|---|---|---|
| Shape | Synchronous request and response, small payloads, immediate result | Asynchronous jobs over large record sets, results collected afterwards | Publish and subscribe — the org tells you what changed instead of being polled | The org initiates the call outward, from Flow or Apex, during a transaction |
| Use it for | A website form creating an Inquiry; a portal looking up one listing; interactive lookups | Nightly MLS loads, data migration, warehouse extracts, backfills | Pushing a status change to a portal within seconds of it happening in the org | Calling a valuation service, an e-signature provider or an internal ledger from a record |
| Do not use it for | Row-by-row loading of a feed — this is the classic design that dies at volume | Anything a user is waiting on, and anything needing an immediate answer | Guaranteed delivery you have not designed a replay path for | Long-running or high-fan-out work; Salesforce caps callouts inside a transaction |
| Watch | Daily API allocation, and per-record error handling on composite requests | Per-record results — a completed job can still contain failed rows | Event retention windows and replay IDs; subscribers must handle redelivery | Callout caps and timeouts inside a transaction, and no callouts after DML |
Deliberately no limit figures above. Daily API allocations, callout caps and Bulk batch sizes vary by edition, licence count and API version, and Salesforce changes them — check the current numbers in Salesforce's own limits documentation for the release your org is on, and design against the shape of the limit rather than a figure you copied from a blog post.
Three tiers of answer to "we need to integrate X". They differ by who maintains the result in two years, which is the only question that reliably predicts total cost.
No code at all. A surprising share of integration requirements are met by configuration on the platform — external ID fields, connected apps, named credentials, external objects and declarative HTTP actions your admin can maintain.
An integration platform carries the plumbing — scheduling, retries, transformation, monitoring — so you own mappings rather than code. The right default for most flows, and the one most firms skip straight past.
Apex, platform events and custom services, for the requirements the first two genuinely cannot express. Scoped as engineering — with tests, a deployment path and somebody named who owns it after we leave.
Propertybase ships in its own namespace. Its code and components are locked — you cannot edit them, and integrations must not assume you can. What you can do in your own org is substantial: add custom fields, including external ID fields, to the packaged objects; write Apex triggers and classes that act on Listing, Property and Inquiry; subscribe to Change Data Capture on those objects; and build Lightning Web Components on top of them. All of that lives in your namespace and survives a package upgrade.
The rule that catches teams out is naming. Packaged objects and fields carry the namespace prefix, so an integration written against unprefixed API names is one sandbox away from breaking. Read the object schema from the org you are integrating with rather than from a document, keep a sandbox on the package upgrade path, and run your integration test set there before production takes a new version. That is the whole discipline, and it is cheaper than any incident it prevents.
The first two are where most of the value is and where most teams under-invest. The last one is the difference between an integration that works and one that stays working.
The architecture decisions that cannot be changed later: which interface, which direction, which key, and what happens when the far end is down. Written down before anybody opens an editor.
RESO Web API and legacy feed handling at brokerage volume, across boards that disagree with each other about what a status means and which fields are mandatory.
Getting the credential model right removes a whole class of outage and a whole class of audit finding. Least privilege, no secrets in code, and rotation that does not require a deployment.
Designing for the night the feed doubles. Salesforce enforces caps on API volume, transaction callouts and concurrency, and an integration that has not been sized against them will find them for you.
Where polling is the wrong answer. Platform events and Change Data Capture let the org announce a change instead of being asked about it every five minutes — with replay semantics you have to design for.
The workstream that is always cut first. An integration estate nobody can observe fails silently, and the cost lands on whoever is holding a deal that day rather than on the team that could fix it.
Most integration problems are a pattern mismatch rather than a coding error. These are the eight that cover almost every Propertybase requirement we are asked to build.
Incremental listing sync paged on a modification timestamp, staged, then written through Bulk as an upsert against the broker listing ID. The correct default for MLS inventory, and the pattern row-by-row REST integrations should have been.
A low-volume, latency-sensitive write from a website or portal creating an Inquiry with the source stamped. Synchronous REST is right here — but the endpoint still needs a duplicate rule, because visitors submit forms twice.
The org publishes when a listing goes under contract; portals and downstream systems subscribe. Replaces a five-minute poll that was both slower and more expensive, provided subscribers handle redelivery.
Listing, Inquiry and transaction changes streamed into a warehouse for analytics that should never run against the production org — the architecture behind reporting at scale. Needs a gap-detection path for the window where the subscriber was disconnected.
Sending a document for signature, requesting a valuation, or posting to a ledger from the record. Callouts are capped inside a transaction and cannot follow uncommitted DML — which is why this pattern belongs in a queueable, not a trigger.
An integration platform owning schedule, transformation, retry and monitoring between Salesforce and a system with no native connector. More expensive per flow than code, and far cheaper across five years and three staff changes.
Salesforce Connect surfaces records that live in another system without replicating them. The right answer for large reference data an agent needs to read and nothing in the org needs to own — and the pattern most often forgotten.
Agentforce and Einstein read the same Propertybase records and write activity back, which makes the integration layer's correctness an AI-quality problem as well as an operations one. Worth building only once the flows above are trustworthy.
Which systems belong in your map at all is the commercial decision on Propertybase integration; the AI layer built on top of these records is Propertybase AI & Agentforce.
An integration that has never been tested failing is an integration that will fail badly. We build the error paths in the same sprint as the happy path, not in the incident review afterwards.
Object and field schema read from the actual org rather than from a document, including namespace prefixes, record types and validation rules that will reject your writes. On the far side, the real API version, its paging model and its rate behaviour under load. Assumptions here are what produce week-six surprises.
Which interface per flow, which external ID each write keys against, what wins on conflict, and the failure contract — what retries, with what backoff, what dead-letters, and who gets told. This document is what you review; everything downstream is an implementation of it.
Built in a sandbox and run at realistic volume, not at demo volume. Bulk sizing and chunking validated against locking behaviour, callout patterns checked against transaction limits, and idempotency proven by replaying the same payload twice and confirming nothing duplicated.
We break it deliberately before production does: far end returning errors, credentials expired, payload malformed, feed twice its normal size. Then the first production run is reconciled by count against the source, with discrepancies resolved before the flow is trusted.
Per-record outcome logging, dead-letter queues with a route back in, freshness and volume monitoring, alerting to a named owner, and a runbook per integration. Handover is not a document drop — your team walks a failure scenario with us before we close the engagement.
Two engagements, both real estate. The first replaced twice-daily manual CSV exports with a REST-based MLS integration and health-check automation. The numbers are the ones those clients measured — scoped exactly as they measured them.
We had Salesforce. We had Propertybase. We had agents using three different follow-up tools. Nothing was connected, and our managing broker was flying blind. Twopir came in, mapped everything, and built a single operating model that our entire team actually uses. We went from not knowing where deals were to having a live dashboard that tells us exactly what's open, what's at risk, and what closed last week.
Manual twice-daily MLS CSV exports replaced with API-based synchronisation and health-check Flows that alert on feed failure.
Commission reconciliation used to take our back office three full days at the end of every month. Agents were questioning their splits, and we had no clean audit trail. Twopir connected our deal records to Accounting Seed and built automated disbursement workflows. We now close commission statements the same day a transaction closes. The trust that has rebuilt with our agents because of that alone has been significant.
Deal records connected to the accounting ledger — commission posting without a manual export.
Twopir Consulting is a Salesforce Partner and a HubSpot Partner. Our integration work is judged on what happens when something goes wrong, because everything works on the day it is demonstrated.
Idempotency designed in rather than patched on. A replayed message, a re-run job or a resent feed page changes nothing twice — which is the single decision that separates integrations that survive a bad night from the ones that duplicate an entire inventory.
Daily API allocation, callout caps, concurrency and Bulk behaviour vary by edition, licence count and API version, and they change. We read the current limits for your org and design against the shape of them rather than a figure somebody memorised three releases ago.
Packaged objects and fields carry the managed package's namespace prefix, and validation rules will reject writes a mapping document never mentioned. We pull the real schema from the real org, which is why our integrations do not break moving between sandboxes.
Far end down, credentials expired, payload malformed, volume doubled. An integration that has never been observed failing has an unknown failure mode, and you will discover it in production at the least convenient moment.
Configuration first, an integration platform second, custom engineering only where neither can express the requirement. Building is the most expensive answer to own — you carry the retries, the monitoring and every API change at the far end — and it is the easiest one to sell.
No, and that is the most useful thing to know before you design anything. Propertybase Salesforce Edition is a managed package installed into your own Salesforce org, so Listing, Property, Inquiry and the transaction records are Salesforce objects that carry the package's namespace prefix. You address them through the platform's own interfaces — REST and Composite for synchronous work, Bulk for volume, and Pub/Sub with platform events and Change Data Capture for streaming — using Salesforce authentication and subject to Salesforce limits. Anything written for the Salesforce API works here; there is no separate Propertybase endpoint to learn.
Bulk, with an incremental pull on the MLS side and an upsert against a stable external ID on the Salesforce side. The pattern that fails is a REST call per record: it is fine at ten listings, and at ten thousand it exhausts the daily API allocation and blocks every other integration in the org. Pull from the RESO Web API paged on a modification timestamp so each run moves only what changed, stage the results, then write them as a Bulk upsert keyed on the broker listing ID or MLS ID. That combination is idempotent, so a re-run after a timeout costs you nothing.
Yes. Platform events let the org publish when something meaningful happens — a listing going under contract, an inquiry being assigned — and Change Data Capture streams record-level changes on the packaged objects without you writing publishers at all. Subscribers connect through the Pub/Sub API. The design work is on the subscriber side: delivery is at-least-once, so consumers must be idempotent, and there is a retention window on the event bus, which means you need a replay strategy and gap detection for the period a subscriber was disconnected. Done properly this replaces a five-minute poll that was both slower and more expensive.
Through a connected app and an OAuth flow chosen for the integration type, with a dedicated integration user on a least-privilege profile — never a named employee's account, which breaks the day they leave. For server-to-server work use a flow that does not require a stored user password, and hold every secret in a named credential rather than in code, a script or a configuration file. That removes an entire class of outage and an entire class of audit finding, and it makes credential rotation a configuration change instead of a deployment. Add IP restrictions and expiry monitoring where the risk profile warrants it.
There are four shapes of limit that matter: a daily allocation of API requests for the org, caps on callouts and their cumulative duration inside a single transaction, limits on concurrent long-running requests, and batch and chunking constraints on Bulk operations. We deliberately do not publish figures for them, because they vary by edition, licence count and API version and Salesforce changes them — check the current numbers in Salesforce's own limits documentation for the release your org is on. What matters architecturally is designing against the shape rather than the number: buffer through a queue so a spike is absorbed, use Bulk instead of per-record REST for feeds, and put backoff, jitter and a ceiling on every retry so one bad minute cannot exhaust the org for everyone else.
Almost certainly, yes. The industry standard has moved from RETS to the RESO Web API — an OData-based interface built on the RESO Data Dictionary — and boards have been retiring RETS access accordingly. Migration is more than a protocol swap: the Data Dictionary standardises field names and enumerations that each board previously expressed its own way, which is an opportunity to fix per-board mapping rather than port it. We treat it as a chance to correct three things at once — the transport, the field and status mapping across boards, and the record key your upserts run against. Confirm your own boards' timelines with them directly, since they retire access on their own schedules.
Not if they are built in the supported way. Custom fields you add to the packaged objects, your own Apex, your external ID fields and your Change Data Capture subscriptions all live in your namespace and survive an upgrade. What needs testing at every release is anything reading a packaged field the vendor may change, and anything that assumed an unprefixed API name. Keep a sandbox on the package upgrade path, run your integration test set there before production takes a new version, and read the object schema from the org rather than from a mapping document. That discipline costs very little and is cheaper than any incident it prevents.
A feed that duplicates on replay, an integration that dies when volume doubles, a RETS-era MLS connection that needs migrating, or a design you would like reviewed before anyone commits to it. We will tell you which pattern it should be — and what its failure path has to look like.
Salesforce architecture, Propertybase delivery & real estate operations
