Can it accept leads from multiple sources into one pipeline?
Yes. Each source posts through its own campaign. The request body names the campaign with a campaignId. The partner uses one posting key for all of its campaigns. Web forms, abandoned carts, and inbound calls all flow into one routing path with one set of reports.
Related: Lead API & Capture
What volume can it handle?
The platform runs on serverless infrastructure that grows on its own. Capacity rises with load, so it handles tens of thousands of leads per day and sudden traffic bursts without you planning for capacity.
Do you support ping-post and batch?
Both are built in. Ping-post is real-time bidding (RTB) for leads. Dedicated ping and post endpoints run through one auction engine, and each buyer sets its own bid. Bulk endpoints cover batch delivery and imports.
Related: Ping-Post
Do you use a ping tree?
Not in the usual sense. A classic ping tree checks one tier of buyers at a time until one accepts. We ping every eligible buyer at once and let their bids compete in one auction. The price that comes back is the best of the whole field, not just the first one that cleared. Delivery then follows the order that the auction produced.
Related: Ping-Post
How does a traffic partner submit a lead to the lead API, and how is that endpoint secured?
Partners post JSON with a bearer posting key scoped to their own campaigns. One partner’s key cannot post to another partner’s campaign. A key can be revoked at once, and the revocation is written to the audit log.
Related: Lead API & Capture
What does the lead API return when a lead is rejected?
A decision in the same HTTP response. The result is success, failed, or error. Once a lead is created, a lead ID comes back so you can match records later. A submission rejected before that point has no lead ID. The price is a decimal string. Rejections include the exact validation or business reason, so a partner can fix their integration without opening a ticket.
Related: Lead API & Capture
What does a ping return in the lead auction, and how long is the bid good for?
A ping returns a ping ID, an expiry timestamp, the number of matched buyers, and a ranked list of prices. No lead is created. Bids can stay valid for one to sixty minutes, set per ping.
Related: Ping-Post
Can our buyers return their own bid price on the ping?
Yes. Each buyer sets its own bid. We call each buyer’s bid endpoint in JSON, XML, or form-encoded format. Sign-in details and a timeout are set per contract. We read the price from the response and drop any bid under that contract’s minimum bid.
Related: Ping-Post
If we ping and then post, do our buyers get pinged twice?
No. The post rebuilds the auction from the stored ping results instead of pinging again, so a buyer never sees the same lead twice and their own duplicate checks are not set off.
Related: Ping-Post
Can the partner choose which buyers to post to after seeing bids?
Yes. The post call accepts the buyers the partner picked from the ping response. Every match they did not pick is still written to the audit trail, so records can be matched up later.
Related: Ping-Post
Can a new partner test their integration end to end before going live?
Yes. A campaign in testing mode accepts real posts and runs them all the way through the routing engine. It returns a trace showing which buyer contracts would have matched. It does not deliver, bill, or show up in production reports.
Can we control which fields are collected?
Field schemas can be set up per vertical. You define which fields exist and which are required, so a routing-only payload works and sensitive data never has to enter the system.
Can a field be required on one campaign and optional on another?
Yes. Campaigns and offers can override the vertical’s field rules. So the same field can be required for one source and optional for another. Fields the rules do not recognize are saved rather than rejected. Any field can be marked as personal data so it is encrypted when stored.
Can we reject bad traffic at the campaign level before it reaches a buyer?
Yes. Each campaign carries its own intake filters, and you choose what a failure means: reject the lead outright, or accept it and pay the partner nothing for it.
How are duplicate leads handled?
Deduplication runs in four layers: suppression lists, per vertical, across partners by matched person, and per buyer at delivery. The vertical and per-buyer layers each let you choose which fields to compare and how far back to look. Identifiers are hashed with SHA-256 before they are stored. Optional fuzzy matching catches near misses in email, phone, and name.
Related: Lead & Caller Deduplication
Can we see the exact payload a partner sent and what we sent back?
Every intake attempt is written to a posting log, whether it was accepted, rejected, unauthorized, rate-limited, or hit an error. The log holds the full request and response bodies, HTTP status, timing, and caller details. An operator can fix and resend a failed submission right from that record.
Do you screen leads for fraud before a buyer sees the lead?
Yes, as an option per offer. Fraud scoring on IP, email, and phone runs at the same time as litigator and do-not-call list checks. A lead can be rejected automatically when its fraud score is above a level you set. Leads also get a quality score at intake when a scoring model is attached to the offer or vertical. You can filter reports by that score and use it as a rule on a contract.
Is there a limit on how large a lead payload can be?
Yes. Oversized payloads are rejected with a 413. The cap is configurable and defaults to 256KB. That keeps a broken partner integration from affecting anyone else’s traffic.
Still have a question?
Pricing is one monthly plan plus published usage rates. Use the setup tools and guides. Some buyer connections need custom field mapping or API work.