Lead API: REST Endpoints for Ping-Post, Submission, and Delivery
Lead Router provides 600+ REST operations. Submit leads, run ping-post auctions, manage buyers and contracts, subscribe to webhooks, and read reports. Each API family documents its sign-in method and response format. Tenant checks limit access to the right account.
600+
Public REST endpoints
Real-Time
Routing decision
Published
OpenAPI spec
Bearer token
Authentication
The API
What the Lead Router API provides
Everything you need to run a lead-distribution operation from code.
Use the API to submit leads, manage supported buyers and contracts, connect campaigns, and read reports. Each API family lists the credentials and permissions it needs. Some actions require administrator access.
The API covers 600+ operations developers can call across ten resource groups: leads, ping-post, buyers, contracts, offers, partners, campaigns, verticals, webhooks, and reports. Requests carry a Bearer token. Responses follow the documented format for each API family, with the paging and error format specified for that API family. Lead submission accepts an idempotency key, so a retry after a timeout returns the original response instead of a duplicate lead.
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 equivalents.
Endpoint Categories
Resource groups in the API
Use the credential, request schema and response contract documented for each API family.
Lead submission
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 private posting key that identifies the partner; campaignId selects the campaign. The response returns the lead ID, the matched buyers, the price paid, and any validation errors.
Ping-post auction
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 personal data (PII). The response includes buyer IDs, bid amounts, and a ping token that scopes the post.
Lead management
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.
Buyer and contract CRUD
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. Administrative operations require the corresponding scoped credentials and permissions.
Partner and campaign CRUD
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.
Webhook subscriptions
POST /api/admin/webhooks
Subscribe an HTTPS endpoint to supported lead or call events in the webhook editor. Set permitted entity scopes, conditions and payload fields. Review delivery logs and retry behavior for the selected event. Webhook settings require the matching administrative permissions.
Reporting and analytics
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.
Authentication
Authorization: Bearer <key>
Use the credential required by the endpoint family. Server lead posting uses a private partner posting key, browser capture uses a campaign publishable key with configured origin restrictions, and administrative or portal APIs use their supported scoped credentials. Rotate or revoke keys through the corresponding settings.
Developer Experience
Built for integration
The things that make an API easy to adopt: OpenAPI spec, documented response contracts, idempotency keys, retryable rate limits, tenant isolation, typed responses.
Published OpenAPI spec
Role-specific OpenAPI specifications describe the supported API surfaces. Generate typed clients in any language, import them into Postman or Insomnia, or plug them into an API gateway. The specs are published and versioned alongside the API.
Documented response contracts
Many resource lists use { data, pagination }, while intake, browser and portal APIs have their own documented responses. Check the relevant specification before implementing success, validation, retry and error handling.
Idempotency keys on submission
Lead submission endpoints accept an Idempotency-Key header. A retry carrying the same key returns the original response instead of creating a second lead, so a network timeout on your side never turns into a duplicate on ours.
Rate limits sized for real traffic
Lead intake allows a burst of 30 requests per 10 seconds and 600 requests per 5 minutes on each API key, with a separate ceiling across all keys in a tenant. A request that exceeds a limit returns HTTP 429 with a Retry-After header that tells you how long to wait. High-volume ingestion can request more headroom.
Tenant isolation
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.
Typed responses
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
One lead submission, start to finish
Minimal request, exact response. The wire response is kept small on purpose: a result, the lead id, the price paid, and a message. The full waterfall (which contracts filtered out, which capped, which bought) is recorded in the posting log on your dashboard.
Request
POST /api/v1/leads/submit HTTP/1.1
Host: theleadrouter.com
Authorization: Bearer pk_YOUR_POSTING_KEY
Content-Type: application/json
Idempotency-Key: 7c3b9d8e-2a4f-4b1c-9d6e-5a7b8c9d0e1f
{
"campaignId": "8f3a1b2c-9e7d-4a5f-b6c8-d1e2f3a4b5c6",
"firstName": "Alex",
"lastName": "Rivera",
"email": "alex.rivera@example.com",
"phone": "+15125551212",
"state": "TX",
"zipCode": "78701",
"tcpaConsent": true,
"consentTimestamp": "2026-09-06T14:32:07.000Z",
"consentText": "The exact disclosure accepted on your form",
"consentCertUrl": "https://your-certificate-provider.example/certificate-id"
}Response
HTTP/1.1 200 OK
Content-Type: application/json
{
"result": "success",
"leadId": "aB3xK9mQ",
"price": "25.00",
"msg": "Lead Accepted"
}Who Uses The API
Built for engineering teams
The Lead Router API fits operations that run lead flow as a production system.
Affiliate networks
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.
In-house engineering teams
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
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.
Connect server posting and browser capture
Choose the credential and specification for the caller that will actually submit the lead.
Private posting keys and browser keys
Keep partner posting keys on your server. Campaign publishable browser keys are made for the browser path and use configured origin restrictions; a publishable key does not grant administrator or partner API access.
Consent fields and campaign requirements
Send flat tcpaConsent, consentTimestamp, consentText, and consentCertUrl fields when required by the campaign specification. Missing tcpaConsent defaults to false. Only send true after capturing actual consent; a certificate URL does not imply consent.
Progressive and co-registration capture
Supported progressive capture can collect data across steps, and co-registration can show other offers you have set up. Keep the source, campaign requirements and consent context when passing data between steps.
Posting specs and landing-page prompts
Generate campaign instructions and supported landing-page prompts from actual field requirements. Up to ten sub IDs preserve source attribution. Use readiness checks and a test submission before sending traffic.
Role-specific documentation
Use the OpenAPI and Postman materials for the relevant admin, buyer or publisher interface. Authentication and response envelopes differ between API families, including posting, browser and portal endpoints.
Integration feedback
Delivery templates, response mapping, scoped webhooks, and ad conversion feedback link the intake record to what happens next. Credentials and event access follow the integration and caller permissions.
Frequently Asked
FAQ
What developers ask before picking up the Lead Router API.
How many endpoints does Lead Router's API provide?
Lead Router provides 600+ developer-callable operations across supported API families. Use the specification for your role: posting keys, browser keys, portal credentials and administrator keys serve different callers, and response envelopes vary by endpoint family.
Is there an OpenAPI spec?
Yes. Separate OpenAPI specs cover the admin, buyer, and partner APIs. Use the spec for your role to build a typed client or import requests into Postman or Insomnia. The specs are versioned with the API.
How does authentication work?
Use the credential required by the endpoint family. Server lead posting uses a private partner posting key, browser capture uses a campaign publishable key with configured origin restrictions, and administrative or portal APIs use their supported scoped credentials. Rotate or revoke keys through the corresponding settings.
Can I migrate from Boberdoo's API?
Map your current lead fields to Lead Router. Create buyers and contracts, then save their new IDs in your integration. Map ping requests to POST /api/v1/leads/ping and accepted posts to POST /api/v1/leads/post. Test delivery before switching traffic.
What is the rate limit?
Lead intake is limited per API key on two windows at once: a burst of 30 requests per 10 seconds and 600 requests per 5 minutes, with a separate ceiling across all keys in a tenant. A request that goes over gets HTTP 429 with a Retry-After header that tells you how long to wait. For high-volume ingestion, contact us about more headroom.
Wire It Up
Grab a key and start posting
Bearer token auth, documented response contracts, OpenAPI spec published. Encryption in transit and at rest, row-level tenant isolation, audit logging. Usage-based pricing. Get started with a test lead.
Every module included at no extra license fee.