Co-listing display on real estate websites
The BrokerFold Team — Product + Engineering
Last reviewed
On this page
Co-listing display is one of those questions nobody covers because it sits in the seam between board compliance and team politics. Two agents share a listing; the website shows one name on the card; somebody feels robbed. We build the render layer that decides what appears, so here is how the mechanics actually work — and where the real decision belongs.
What the feed knows
Modern board feeds — TRREB’s RESO Web API among them — carry listing attribution as structured data: the listing agent, the listing brokerage, and, where a second agent shares the listing, co-listing agent and brokerage fields. So the raw material distinguishes the roles cleanly. The display question is never “who is on the listing?” — the feed answers that — it is “which of these fields render, where, at what size?”
What must render, regardless of preference
Board display rules require listings shown on a member website to carry the listing brokerage attribution — the “listed by” line — and boards prescribe where and how prominently it appears. That line is not negotiable and not editable to suit in-team credit. The broader mechanics of that requirement are covered on our listing attribution page; everything below assumes the compulsory layer renders correctly.
Card versus detail: the practical convention
Listing cards are small. A card that tries to carry two agent names, two brokerages, and a price becomes unreadable, which is why the working convention across well-built sites is: the card carries the required brokerage attribution; the detail page carries the fuller picture, including the co-listing side where the feed provides it. A visitor who cares who represents the seller is on the detail page anyway. Teams sometimes ask for both names on every card — resist it; you are spending your scarcest asset, card legibility, on an internal courtesy.
In-team credit is a different ledger
Here is the distinction that dissolves most co-listing arguments: public display answers to the board; credit answers to the team. Whether the mentor or the junior “gets” the listing on the website is the wrong question, because the website renders what the MLS record says. The right questions are internal: whose featured band does the property appear in — and a co-listing can legitimately appear in both — who fields the sign calls, and how the commission splits. Write those answers down before the first co-listing, not after, ideally inside your rules of engagement.
Common failure modes we see
Three patterns cause nearly all co-listing grief on team sites. First, manual overrides: someone edits a display name to add the junior agent, and the site now shows attribution the MLS record doesn’t support. Second, stale records: the co-list agent was added at the board after launch and the site never re-synced — a pipeline problem, not a policy one, and a reason to care how fresh your feed sync is. Third, silent expectations: nobody agreed what co-listing means for credit, so every instance becomes a negotiation. The first two are solved by running a compliant render layer that you never hand-edit; the third only by a conversation.
The one-paragraph policy worth adopting
The public display renders exactly what the feed carries, per board rules, always. Internally, a co-listing counts toward both agents’ production, appears on both bio pages, and splits per the written agreement made when the listing was signed. Adopt that, and co-listing display stops being a recurring argument and becomes what it should have been all along: plumbing.
One further note for teams that co-list often as a mentorship device — senior agent plus junior on every file. The pattern is excellent for development and mildly awkward for the website, because the junior’s profile fills with shared credits before it holds solo ones. Lean into honesty rather than inflation: label mentored files naturally in the bio copy (“co-listed with…” reads as apprenticeship, which clients respect), and let the solo listings arrive on their own schedule. A transparent record builds a junior’s credibility faster than a padded one ever will.
Frequently asked questions
Does the MLS feed identify both agents on a co-listing?
Generally yes. RESO-based feeds carry the listing agent and a co-listing agent as separate fields, along with their brokerages. What a website chooses to render from those fields is a display decision — the data itself distinguishes the two roles.
Whose brokerage must be credited on a co-listed property?
The listing brokerage of record — and where two brokerages co-list, board display rules govern how attribution renders. The safe posture for any website is to render the attribution the feed provides rather than editing it to flatter one side.
Can our team site show only our own agent on a co-listing with an outside brokerage?
No. Suppressing the required attribution because the co-operating side isn't yours is exactly the kind of display edit board compliance rules exist to prevent. Credit renders as the board requires; your team's internal credit conventions live in your CRM and your commission ledger, not in the public display.
Keep reading
- Listing attribution on team sites What Canadian MLS display rules require on every listing card, how team sites get attribution wrong, and how to feature your own inventory honestly.
- Featured listings by agent on team sites How to give each team member a listings presence on the shared site — per-agent bands, bio-page inventory, and the empty-state problem solved honestly.
- CRM rules of engagement for real estate teams The written rules that stop lead disputes: ownership, work standards, forfeiture timers, and carve-outs — enforced by CRM states instead of arguments.
- TRREB IDX website A TRREB IDX website with the board's live feed: 15-minute sync via RESO Web API, photos on our own CDN, and listings that publish only when complete.