Is this a marketplace, or do we control our own buyers?
The platform is fully multi-tenant. Your buyers and call centers live inside your own private tenant, receiving leads exclusively from you. There is no shared marketplace, and no outside party ever sees your leads.
What distribution logic is supported?
Priority/waterfall, round robin, weighted, and price-based distribution, with daily, weekly, and monthly volume and spend caps per buyer, hours-of-operation schedules, geo, demographic and custom filters, and concurrency controls on calls.
Related: Waterfall Routing
Are there distribution rules beyond priority and round robin?
Six in total: price, priority, weighted random, round robin, quality tier, and scarcity-weighted — which paces delivery against live state and ZIP-level scarcity so hard-to-fill geographies are not starved by whichever buyer has the largest cap.
Related: Waterfall Routing
Can different lead types have different rules?
Yes. Rules live on the offer, so each lead type runs as its own offer with independent rulesets, caps, and buyer lineups.
What happens when a buyer is at capacity or offline?
Automatic waterfall. The engine cascades to the next eligible buyer in real time, and every step is logged so you can see exactly why each lead landed where it did.
Related: Cap Management
Can we prove why a lead went to one buyer and not another?
Every contract the engine evaluates writes a record — eligible, skipped or rejected — carrying the named reason and the expected-versus-actual result of each individual filter. The full waterfall stays on the lead, so any routing decision can be reconstructed months later.
Related: Waterfall Routing
How granular can buyer filters get?
Three layers per contract: geography (state allow or exclude lists plus ZIP-prefix targeting), demographics, and fully custom rules on any field in your schema — including nested fields — with operators for equals, in, not in, contains, greater than, less than, and empty or not empty.
Can we filter on a relative date, like a bankruptcy older than two years?
Yes. Date comparisons accept relative expressions such as “2 years ago” or “6 months ago”, so a contract’s rules stay correct on their own instead of needing someone to edit a fixed date every month.
Can we stop sending leads to a buyer outside their business hours?
Yes. Each contract carries a weekly hours-of-operation schedule evaluated in that buyer’s own timezone, including overnight windows that cross midnight.
Can we cap a buyer by volume and by spend, and whose timezone do caps use?
Both, independently, on daily, weekly and monthly cycles — a lead-count cap and a dollar spend cap per contract. Periods roll over on your account’s timezone rather than UTC.
Related: Cap Management
Under a burst of traffic, can a buyer be pushed past its cap?
No. Cap counters increment atomically at the moment of sale with the limit checked inside the same operation, so two simultaneous leads cannot both slip through — and if that sale later fails, the cap slot is automatically returned.
Related: Cap Management
Can we map our field names to each buyer’s field names without custom code?
Yes. Delivery is configured per contract with per-buyer field mapping and default values, plus over 50 built-in transformers covering case, math, dates and age, timezones, string operations, encoding, conditionals and state expansion — all from the UI.
How do you know whether a buyer accepted or rejected a lead?
We evaluate the buyer’s actual response body against rules you define, not just the HTTP status — so a 200 whose payload says “rejected” is correctly counted as a rejection. Values from that response are written back onto the sale, including the buyer’s own lead ID and any adjusted price they return.
Can we test a buyer integration before sending live traffic?
Yes. A test delivery fires a real request through the exact production mapping path — same transformers, same defaults — and shows you the literal URL, headers and body sent alongside the buyer’s response.
Do you retry a failing buyer endpoint, or keep sending into a black hole?
Delivery attempts can be retried with exponential backoff, and automated delivery-health monitoring pauses a persistently failing endpoint instead of burning leads on it.
What happens if every eligible buyer rejects the lead?
The lead falls through to your configured DQ contracts, so it can still be monetized rather than discarded — and an operator can re-deliver or cherry-pick it to a chosen buyer afterwards.
Related: Waterfall Routing
Still have a question?
Pricing is a flat plan plus published usage rates, and a build is configuration rather than custom development. Start where it makes sense for you.