All FAQs

Lead Intake & API

Getting leads into one pipeline, and what the intake layer can do once they arrive.

17 questions answered

Can it accept leads from multiple sources into one pipeline?

Yes. Each source posts through its own campaign with its own API key, and all sources — web forms, cart abandons, inbound calls — converge into a single routing pipeline with unified reporting.

Related: Lead API

What volume can it handle?

The platform runs on fully serverless, auto-scaling infrastructure. Capacity scales horizontally with load, so tens of thousands of leads per day and traffic bursts are handled without capacity planning.

Do you support ping-post and batch?

Both, natively. Dedicated real-time ping and post endpoints run through a unified auction engine with buyer-authoritative bidding, plus bulk endpoints for batch delivery and imports.

Related: Ping-Post

How does a traffic partner submit a lead, 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 instantly, and the revocation is written to the audit log.

Related: Lead API

What does your API return when a lead is rejected?

A decision in the same HTTP response: accepted or rejected, a lead ID for reconciliation, the payout, and the specific validation or business reason for a rejection — so a partner can fix their integration without opening a ticket.

Related: Lead API

What does a ping return, 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 — without creating a lead. Bid lifetime is configurable from one to sixty minutes per ping.

Related: Ping-Post

Can our buyers return their own bid price on the ping?

Yes — bids are buyer-authoritative. We call each buyer’s own bid endpoint in JSON, XML or form-encoded format with per-contract authentication and timeout, read the price out of their response, and discard anything under that contract’s minimum bid floor.

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 rather than re-pinging, so a buyer never sees the same lead twice and their own duplicate checks are never tripped.

Related: Ping-Post

Can the partner choose which buyers to post to after seeing bids?

Yes. The post call accepts the specific buyers the partner selected from the ping response, and every match they did not select is still written to the audit trail for reconciliation.

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, returning the routing trace of which buyer contracts would have matched — while suppressing delivery, billing, and production reporting.

Can we control which fields are collected?

Field schemas are fully configurable per vertical. You define which fields exist and which are required, so a routing-only payload is fully supported 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 override the vertical’s schema, so the same field can be mandatory for one source and optional for another. Unrecognized fields in a payload are captured rather than rejected, and any field can be flagged as personal data so it is encrypted at rest.

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, per-vertical, cross-partner by resolved person, and per-buyer at delivery — with the vertical and per-buyer layers each carrying their own configurable field set and lookback window. Identifiers are SHA-256 hashed before storage, and optional fuzzy matching is available for near-miss email, phone and name variants.

Related: Lead Deduplication

Can we see the exact payload a partner sent and what we sent back?

Every intake attempt — accepted, rejected, unauthorized, rate-limited or errored — is written to a posting log with the full request and response bodies, HTTP status, timing and caller details. An operator can correct and replay a failed submission straight from that record.

Do you screen leads for fraud before a buyer sees the lead?

Optionally, per offer. Fraud scoring on IP, email and phone runs in parallel with litigator and do-not-call list checks, and a lead can be auto-rejected above a threshold you configure. Leads are scored for quality at intake when a scoring model is attached to the offer or vertical, and that score is filterable in reporting and usable as a contract gate.

Is there a limit on how large a lead payload can be?

Yes — oversized payloads are rejected with a 413, at a configurable cap that defaults to 256KB. That keeps a malfunctioning partner integration from affecting anyone else’s traffic.

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.