Lead Router ships with more than 330 public REST endpoints. Submit leads, run ping-post auctions, manage buyers and contracts, subscribe to webhooks, and pull reporting. Bearer token auth, one response envelope, OpenAPI spec published, tenant isolation enforced at the database layer.
330+
Public REST endpoints
Sub-100ms
Average routing latency
Published
OpenAPI 3.1 spec
Bearer token
Authentication
The API
A complete surface for building a lead-distribution operation in code, not clicks.
Lead Router is developer-first. Every action available in the admin UI is also a public API call. Create a buyer, write a contract, wire up a partner, launch a campaign, post a lead, run a ping-post auction, subscribe to a webhook, pull a revenue report. Same endpoints, same auth, same response shape.
The API covers 330 plus public endpoints across ten resource groups: leads, ping-post, buyers, contracts, offers, partners, campaigns, verticals, webhooks, and reports. Requests carry a Bearer token. Responses use a single envelope shape with consistent pagination and error codes. Idempotency keys are supported on every mutation so retries are safe.
If you run an operation today on Boberdoo, LeadConduit, Phonexa, or Ringba, the migration path is mapping your existing posting fields to the Lead Router lead submission schema and pointing traffic at the new endpoint. Ping-post, cherry-pick, and webhook subscriptions all have direct analogues.
Endpoint Categories
Every category uses the same auth, the same envelope, and the same error shape. Learn one, learn them all.
POST /api/v1/leads/submit
Post a lead from a landing page, call center, or upstream system. The payload carries vertical-specific fields, consent records, and a posting key that identifies the partner and campaign. The response returns the lead ID, the matched buyers, the price paid, and any validation errors.
POST /api/v1/leads/ping then /post
Two-step auction: ping with redacted data to get bids from eligible contracts, then post the full record to the winners. Use this when you sell into an exclusive or hybrid offer and need to price the lead before revealing PII. Response includes buyer IDs, bid amounts, and a ping token that scopes the post.
GET, PATCH /api/v1/leads
List leads with filters (dateRange, vertical, status, buyer, partner), fetch a single lead with full distribution history, update disposition, or bulk-update status. The cherry-pick endpoints let a buyer claim specific leads from an inbox queue at a posted price.
GET, POST, PATCH, DELETE /api/v1/buyers, /contracts
Create buyers, set contract filters (geo, demographic, custom fields), configure caps (daily, weekly, monthly, concurrency), set pricing, and attach to offers. The same endpoints that power the admin UI are public, so every configuration change is scriptable.
GET, POST, PATCH /api/v1/partners, /campaigns
Onboard partners, generate posting keys for their campaigns, set payouts, and gate traffic with per-partner allow-lists. Campaign records carry the posting spec that partners consume when wiring their form or call source.
POST /api/v1/webhooks
Subscribe an HTTPS endpoint to lead events: lead.created, lead.sold, lead.rejected, buyer.capped, contract.updated. Deliveries are signed with HMAC, retried with exponential backoff, and logged for replay. Use webhooks instead of polling when you need real-time downstream updates.
GET /api/v1/reports
Run aggregate queries for revenue, margin, cap utilization, buyer performance, partner performance, and rejection reasons. Filters cover date ranges, verticals, partners, buyers, and custom tags. Responses are paginated with the standard envelope and include pre-computed totals for charting.
Authorization: Bearer <key>
Every request carries an Authorization header with a Bearer token. Keys are scoped per role (admin, buyer, partner, superadmin) and per tenant. Keys can be created, rotated, and revoked from the admin UI. Rate limits and quotas are enforced per key and reported in response headers.
Developer Experience
The things that make an API easy to adopt. OpenAPI spec, consistent envelope, idempotency keys, rate limit headers, tenant isolation, typed responses.
Full OpenAPI 3.1 spec covers every public endpoint. Generate typed clients in any language, import into Postman or Insomnia, or plug into an API gateway. Kept in sync with code via automated validation on every deploy.
Every list endpoint returns { data, pagination }. Every error returns { error: { code, message, details } }. No transformations, no per-endpoint quirks. Write one client wrapper and reuse it everywhere.
POST and PATCH endpoints accept an Idempotency-Key header. Retried requests with the same key return the first response, not a duplicate. Safe to retry lead submissions, contract updates, and webhook registrations on network failures.
Every response carries X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset. Rate limits are published per plan tier. High-volume ingestion can request dedicated capacity with burst headroom.
API keys are bound to a tenant. A partner key cannot read another tenant's leads. A buyer key cannot call partner endpoints. Every query is filtered by tenant in the database layer, not just the route handler.
Zod schemas define request and response shapes and are shared between server and client code. Response types match the OpenAPI spec. Breaking changes go through a versioned release, not a silent schema shift.
In Practice
Minimal request, full response. The distribution array shows the waterfall: which contracts filtered out, which capped, which sold.
Request
POST /api/v1/leads/submit HTTP/1.1
Host: leads.iscale.com
Authorization: Bearer ck_live_4f8a2b1c9e7d3a5f6b8c
Content-Type: application/json
Idempotency-Key: 7c3b9d8e-2a4f-4b1c-9d6e-5a7b8c9d0e1f
{
"campaignId": "8f3a1b2c-9e7d-4a5f-b6c8-d1e2f3a4b5c6",
"postingKey": "pk_live_3d9e7a5f1b2c8d6e4a7b",
"firstName": "Alex",
"lastName": "Rivera",
"email": "alex.rivera@example.com",
"phone": "+15125551212",
"state": "TX",
"zip": "78701",
"consent": {
"timestamp": "2026-04-18T14:32:07.000Z",
"ip": "198.51.100.42",
"userAgent": "Mozilla/5.0",
"language": "TCPA express written consent..."
}
}Response
HTTP/1.1 200 OK
Content-Type: application/json
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 997
X-RateLimit-Reset: 1714492800
{
"data": {
"id": "0a1b2c3d-4e5f-6a7b-8c9d-0e1f2a3b4c5d",
"shortId": "LD-8K4M2N",
"status": "sold",
"createdAt": "2026-04-18T14:32:08.412Z",
"sales": [
{
"buyerId": "b12a3456-7890-bcde-f012-345678901234",
"contractId": "c98f7654-3210-dcba-9876-543210fedcba",
"price": "42.50",
"deliveryStatus": "delivered"
}
],
"distribution": [
{ "contractId": "c11111...", "outcome": "filtered", "reason": "geo_mismatch" },
{ "contractId": "c22222...", "outcome": "capped", "reason": "daily_cap_reached" },
{ "contractId": "c98f76...", "outcome": "sold", "price": "42.50" }
]
}
}Who Uses The API
The Lead Router API earns its keep in operations where lead flow is a production system, not a one-off setup.
Affiliate networks with custom lead-gen systems wire their existing infrastructure to the Lead Router API. Post leads from their platform, run ping-post against the buyer pool, pull reporting into their partner dashboards, and subscribe to webhooks for real-time payout updates.
Teams migrating off Boberdoo, Phonexa, or LeadConduit map their existing posting schemas to the Lead Router lead submission endpoint, recreate buyer and contract records via the CRUD endpoints, and cut over traffic in phases. Ping-post and cherry-pick patterns port directly.
Direct advertisers wire their CRM and sales platform to the API. Submit leads from their forms, route to internal teams through contracts, and push sold leads back to their CRM through webhook deliveries. No CSV exports, no manual sync.
Frequently Asked
What developers ask before picking up the Lead Router API.
How many endpoints does Lead Router's API provide?
Lead Router publishes more than 330 public REST endpoints. They cover lead submission, ping-post auctions, lead management and cherry-pick, buyer and contract CRUD, partner and campaign CRUD, webhook subscriptions, reporting, and authentication. Every endpoint returns the same envelope shape and uses the same Bearer token auth, so adding a new integration does not require learning a new pattern.
Is there an OpenAPI spec?
Yes. Lead Router publishes a full OpenAPI 3.1 spec covering every public endpoint. You can use it to generate typed clients in any language, import it into Postman or Insomnia, or plug it into an API gateway. The spec is kept in sync with the code through automated validation on every deploy.
How does authentication work?
Every request carries an Authorization header with a Bearer token. API keys are scoped per role (admin, buyer, partner, superadmin) and per tenant, so a partner key cannot read another tenant's leads and an admin key cannot call partner-only endpoints. Keys can be rotated and revoked from the admin UI. Rate limits and quotas are enforced per key.
Can I migrate from Boberdoo's API?
Yes. Migration paths are documented for Boberdoo, LeadConduit, Phonexa, and Ringba. The pattern is to map your existing posting fields to the Lead Router lead submission schema, reuse the same buyer IDs in contract records, and point your traffic at the new endpoint. Ping-post works the same way: map ping request fields to POST /api/v1/leads/ping and post-accept fields to POST /api/v1/leads/post.
What is the rate limit?
Rate limits are published per plan tier in the API docs and enforced per API key. Headers on every response report the limit, remaining calls, and reset timestamp. For high-volume ingestion, contact us about dedicated capacity and burst headroom.
Wire It Up
Bearer token auth, one response envelope, OpenAPI spec published. Architected for SOC 2 Type II and HIPAA, audit in progress. Usage-based pricing, free trial to start.
No credit card required. All features included from day one.