LeadMove Docs
Buyers

Buyer portal access

Give a buyer a login to see its own leads and raise disputes, and manage that login afterwards.

Buyer page → Portal access → Enable portal access. Set the email the buyer will sign in with and a password of at least 8 characters, then send both to your contact, along with your portal address.

The card names that address for you, so what you send is always the right one. It is portal.leadmove.io by default; point your own domain at it — portal.acme.com — in custom portal domain, and once that domain is active the card switches to it, with the sign-in page carrying your branding before the buyer even logs in.

Portal access is optional and per buyer. A buyer without it still receives leads normally.

Managing the login

Once active, the card shows the login email (one click to copy), the last login, and a collapsible list of recent sign-ins. The menu holds everything else:

ActionEffect
Reset passwordSets a new password. Send it to the buyer — LeadMove doesn't email it.
Change emailThe buyer signs in with the new address; the password is unchanged.
Disable portalThe buyer can no longer sign in. The password and login history are cleared, so re-enabling means setting a new password.

Buyers can change their own password from their profile once they're in — they need the current one, and doing so signs out their other devices. It shows in your activity log. What they can't do is reset a password they've forgotten: the portal can't email them, so that still comes back to you. They also can't change their own email.

What the buyer sees

Its own deliveries, and nothing else:

  • A dashboard with this cycle's delivered / on-the-way / failed counts, open disputes, quota usage and a 30-day volume chart — plus daily / weekly / monthly spend totals if you've switched Lead prices & spend on.
  • Leads: every lead delivered to it — searchable by email, phone or reference — with the full record and a CSV export.
  • Disputes: the disputes it raised and how you resolved them.
  • Profile, behind the account menu: name, login email, status, quota usage, their operating hours, and a password change form. Everything else is marked as managed by you.

The portal carries your brand — name, logo and accent colour — and you choose what it exposes. See customize the buyer portal.

Choosing the fields

By default a buyer reads every field the lead arrived with. Buyer page → Portal access → Lead fields → Edit to change that: one switch per field, off means hidden.

Hiding a field removes it from the lead page, the leads list, the CSV export, the dashboard and the disputes list at once — there is no screen where it survives. Hide email or phone and the contact column goes with it, so the setting can't be worked around by reading the list instead of the lead.

Two shortcuts sit at the top of the panel. Only delivered fields leaves visible exactly what this buyer's rules deliver to its endpoints, and hides the rest. Show all puts everything back.

A last switch, Fields outside your pipeline schemas, covers whatever a source posts that no schema declares — those keys change from lead to lead, so they share one decision.

Delivery is never affected. What each endpoint receives is set by the field mapping on the routing rule, in routing rules. This setting is about what the buyer reads on the portal, nothing else.

What the buyer never sees

  • Money — unless you switch Lead prices & spend on in customize the buyer portal: then each lead shows its price and the dashboard totals their spend. Invoices and the prepaid balance never appear either way.
  • Your other buyers, your pipelines, your volumes.
  • Your internal quality work: scores, grades, validation and routing data are stripped from the lead before it reaches the portal.
  • Any field you hid for that buyer under Lead fields, on every screen and in the export.
  • Your infrastructure: a delivery that failed on your side reads as "Retrying", not as an error trace.

Portal engagement

Once a buyer has portal access, its page gains a Portal engagement card under the KPI cards on the Overview tab: how many of the leads delivered in the selected period the buyer opened, how long it typically took them, and what they reported back — New, Viewed, In progress, Sold, Lost. A buyer without a portal that reports through the Reporting API, or on which you set outcomes yourself, gets the same card as Reported outcomes, without the "opened" half.

Under the close rate, a Sold rate line counts sold leads over delivered ones and adds up the amounts reported on those sales, in the buyer's currency: Sold rate 18% — 9 sold leads of 50 delivered · $12,400 reported.

It follows the same date range as the cards above it, measured on when each lead was delivered.

"Opened" means one precise thing: somebody signed in as that buyer and opened that lead's own page in the portal. Not a sign-in. Not a CSV export. It is a read receipt per lead, stamped once, the first time — so a buyer who downloads everything and reads nothing does not show as engaged.

Every rate names its denominator, e.g. Close rate 63% — of 8 leads with a reported outcome, 17 delivered have none. Sold and Lost are optional for the buyer, so the declared half of this card will always be partly empty. Close rate is Sold ÷ (Sold + Lost) — never Sold ÷ delivered, which would read every unreported lead as a loss.

Per lead

The same two facts show up wherever you look at one lead — on its page under each delivery, and in the leads panel:

  • the read receipt: Viewed 2 h after delivery, or Not viewed yet;
  • the outcome, with who reported it: Reported in portal · Sold, Reported by Acme via API · Enrollment · $1,240, or Set by Alexis · Lost.

The lead's activity timeline records every declaration as it happens, and keeps them for two years: Viewed in the portal by Acme, Marked Sold — reported by Acme via API · Enrollment · $1,240. Several declarations can follow each other on one lead; the latest is the one shown on the delivery, the timeline keeps the rest.

Set outcome

Each delivered row on the lead page has a Set outcome menu: In progress, Sold, Lost, and Clear status once one is set. Picking Sold asks for an optional amount, in the buyer's currency, and an optional label (the buyer's own stage name, "Enrollment"). Use it when a buyer tells you over the phone, or when you reconcile a buyer's report by hand.

An outcome you set reads Set by you on the lead and in the timeline, so it is never mistaken for the buyer's own word. It works whether or not the buyer has a portal, and whether or not lead statuses are switched on for the portal: that toggle decides what buyers may do, not what you may record. If the pipeline has a conversion postback on Lead reported sold, marking Sold fires it, once, like a buyer's own report would (conversion postbacks).

Across the log

The leads log has a Buyer reported filter: In progress, Sold, Lost, or No status reported. It selects the same leads the buyer's own badge does. Combine it with Delivery Status: Delivered to get the useful version of the last one: leads that reached a buyer and came back with no verdict.

Switching the portal side of the feature off for everyone lives in customize the buyer portal — engagement you already collected stays on the buyer's page either way, and Set outcome keeps working for you.

Reporting API

A buyer whose leads live in a CRM does not need the portal to report outcomes. The Reporting API card, in Portal & credits next to the portal card, holds a key that buyer's systems present on the lead outcomes API: in progress, sold or lost, their own stage name, the sale amount.

Generate key shows the key once, with a ready-to-run request. Copy it, send it to the buyer's technical team with the link Send this page to your buyer's team, and you are done: nothing else to configure. Outcomes they report read Reported by Acme via API on the lead, with their label and amount, and count in the buyer's engagement figures like a portal report.

Rotate creates a second key so the buyer can switch over before the first is revoked; two keys can be active at once. Revoke cuts a key immediately. Neither the key nor its use shows in Settings → Developers, which lists your organization's own keys only.

The API follows the same switch as the portal: if lead statuses are off in customize the buyer portal, the buyer's requests are refused with outcomes_disabled. A buyer's key holds exactly one right, reporting on its own leads; it can read nothing and act on nothing else.

Once a key exists, the card counts the week's calls, as "4 requests · 2 errors · last 7 days", and View requests → opens the list in a side panel: the last 50 calls made with the buyer's keys, with the time, the path, the HTTP status (green when accepted, amber when refused, red when rate limited or failed on our side), the error code and the lead. The chevron on a line opens the exact request and answer. That is where "our integration does not work" gets settled: a lead_not_found says the reference they sent is not a lead they were delivered, a key_revoked says which key they still run on. The same request shows on the lead, under the reported outcome, as View request. Requests are kept 180 days; the buyer never sees this list.

Share the how-to

These pages are written for the buyer — send the links as-is:

Common questions

Does disabling the portal stop deliveries? No. Portal access and lead delivery are independent. To stop leads, pause the buyer's rule in the pipeline or the buyer itself — see Adding buyers.

Can several people at the buyer use the portal? There's one login per buyer. Share the credentials, or create separate buyers if they need separate views.

Can the buyer dispute a lead without the portal? Yes — they tell you, and you open the dispute from the lead page. See How disputes work.

Does the portal show my brand? It shows the portal name and logo set in your account settings, not LeadMove's.

Why does a buyer show no engagement data? Because it has no portal access. A buyer you deliver to by webhook, email or Google Sheets never opens a portal, so showing it "0% opened" would say something false about it rather than something weak. Enable portal access and the card appears — for leads delivered from then on, since nothing was tracked before.

Can I change a status a buyer set? You can set your own, from Set outcome on the lead page, and it then reads Set by you rather than reported by the buyer: the provenance is always shown, so a figure the buyer gave is never silently rewritten as theirs. Nothing hangs off an outcome either way: no price, no cap, no dispute, no invoice. The one exception is a conversion postback on Lead reported sold, which fires whoever reports the sale.

Do these statuses exist for buyers without the portal? The read receipt does not: it needs somewhere to be read. Outcomes do, two ways. The buyer's systems can report them through the Reporting API, and you can set one yourself from the lead page (Set outcome). Everything else about that buyer — deliveries, disputes, caps, billing — works exactly the same.

On this page