Feature

Lead Cap Management: Daily, Weekly, and Monthly Volume Controls

Cap management controls how many leads each buyer takes per period. Lead Router enforces caps with atomic counters in the capCounter table and timezone-aware rollovers so oversells do not happen and period resets land in the buyer's business day, not UTC.

Atomic

Increment model

Timezone-aware

Period rollovers

Daily / Weekly / Monthly

Period types

The Basics

What cap management is

How operators control buyer volume without oversells.

Cap management is the control layer that decides how many leads a buyer contract will accept in a given period. Every contract can set a daily cap, a weekly cap, and a monthly cap. Once a cap is hit, the contract stops taking new leads until the period rolls over. Caps are how operators honor a buyer's budget, a carrier's weekly allotment, a lender's daily commitment, or a local agent's crew capacity.

Lead Router stores cap state in the capCounter table, one row per contract per period type. Increments are atomic, rollovers happen in the tenant timezone, and cap checks run inside the ping phase so a capped buyer never returns a bid on a lead it cannot actually take. That is the difference between caps that work under load and caps that oversell every Monday morning.

Capabilities

What Lead Router's cap management does

Six capabilities that separate production-grade cap enforcement from the spreadsheet version.

Three period types per contract

Every buyer contract supports a daily cap, a weekly cap, and a monthly cap, all three configurable independently. A contract can run with only a daily cap, only a monthly cap, or any combination. Whichever period hits first stops the contract from accepting new leads until that period rolls over. Each period maintains its own counter row in the capCounter table so the three counters do not interact or conflict.

Atomic counter increments

Cap increments are atomic at the database level. When 20 concurrent pings all try to hit the same contract in the same millisecond (a common scenario during a ping-post burst on a hot offer), Lead Router uses a single atomic SQL update so only the remaining capacity succeeds. No two pings can both push the counter past the cap. Naive implementations that read-then-write allow oversells by N concurrent requests. Lead Router does not.

Timezone-aware period rollovers

Caps reset at midnight in the tenant’s configured timezone, not UTC. An Eastern carrier’s daily cap resets at 12am ET. A Pacific operator’s daily cap resets at 12am PT. Weekly caps reset on the tenant’s configured week-start day. Monthly caps reset on the first of the month in the tenant timezone. The DB runs in UTC but every period boundary is computed against the tenant timezone, so a buyer’s business day matches their cap behavior.

Caps enforced during the ping phase

Cap checks run inside the ping auction. A contract that is capped out does not return a bid, which means capped buyers are never in the winner pool. This keeps the waterfall clean (no wasted evaluations), saves compute on offers with high contract counts, and prevents the source from seeing stale bids from buyers who cannot actually take the lead. Capped contracts are logged in leadDistribution with the exact reason so the audit trail is complete.

Per-period visibility in the admin

The admin dashboard shows remaining cap for every active contract across all three period types. Contracts can be sorted by how close they are to cap so operators can spot the ones about to hit. Each contract detail page shows live counter values, the next rollover timestamp in the tenant timezone, and a history of period rollovers. Alerts can fire when a contract crosses a threshold (80% of daily cap, 90% of monthly cap, etc.).

Cap increments tied to sale, not ping

The cap counter increments only when a leadSale row is written. A ping that wins but the source never posts the full lead does not eat capacity. A full post that the buyer rejects with a non-2xx does not eat capacity. Only actual sold leads count. Operators get the full budget they pay for. Naive implementations that increment on the ping leave capacity on the table every time a post fails or the source abandons the auction.

Use Cases

Who runs caps this way

Four buyer profiles where cap management is the control that keeps the business honest.

Auto insurance carriers

Carriers with strict monthly budgets set a monthly cap that matches the budget in dollars, then set a daily cap at roughly budget-over-business-days so the spend lands evenly. Without a daily cap, a single hot day on a ping-post offer can burn a full month of budget in eight hours.

Medicare carriers during AEP

Annual Enrollment Period runs October 15 through December 7. Carriers with AEP weekly surge caps raise weekly limits on the agent-rich contracts and drop them back on the others. Weekly caps reset at midnight on the tenant’s configured week-start day so the allotment matches the carrier’s reporting week.

Mortgage lenders

Lenders with daily volume commitments set a daily cap that matches the commitment, guaranteeing the partner the agreed volume and stopping the lender from overbuying. Daily caps reset at midnight in the lender’s timezone so the daily number matches the lender’s operations day, not UTC.

Solar installers

Local installers are capacity-constrained by crew availability. A daily cap of 6 leads per day per installer matches crew throughput. Hit the cap, contract stops taking leads, installer does not get buried on a Monday and cancel on a Wednesday. The dashboard shows which installers are near cap so intake can redistribute.

Common Mistakes

What operators get wrong about caps

Three failures that show up the moment a system starts running real volume. Lead Router fixes all three.

Incrementing on ping instead of sale

Naive implementations increment the counter when the ping wins, not when the full lead is sold. Every rejected post, every abandoned auction, every 500 from the buyer eats capacity that never got paid for. Lead Router increments only on a successful leadSale row. A buyer that rejects the post keeps the capacity for the next lead.

Using local-server timezone instead of tenant timezone

Cap resets that fire at UTC midnight mean a California carrier’s daily cap resets at 4pm local time on the prior day. A cross-region team sees caps reset in the middle of the business day and gets blamed for oversells that are actually the reset catching the tail of yesterday’s traffic. Lead Router computes every period boundary in the tenant timezone.

Allowing race conditions on concurrent writes

Read-then-write cap increments allow oversells by N concurrent requests. A cap of 50 with 60 concurrent pings can land at 55 sold because two pings both read 48, both added 1, and both wrote 49. Lead Router uses an atomic SQL increment so only the first (capLimit - capUsed) writes succeed and the rest see 0 remaining.

Frequently Asked

FAQ

The questions operators ask before running caps on a platform.

What's a lead cap?

A lead cap is the maximum number of leads a buyer contract will accept in a given period. When the cap is hit, the contract stops accepting new leads until the period rolls over. Caps are how operators enforce a buyer’s budget, a carrier’s weekly allotment, or a local agent’s crew capacity. Lead Router supports daily, weekly, and monthly caps per contract, each configurable independently.

Can I cap by day, week, and month?

Yes, all three, independently configurable per contract. A contract can have a daily cap of 50, a weekly cap of 300, and a monthly cap of 1,000 all at the same time. Whichever period hits first stops the contract from taking more leads. Each period type maintains its own counter row in the capCounter table and rolls over on its own schedule.

When does the cap reset?

Caps reset at midnight in the tenant’s configured timezone, not UTC. An Eastern carrier’s daily cap resets at 12am ET. A Pacific operator’s daily cap resets at 12am PT. Weekly caps reset at midnight on the tenant’s configured week-start day. Monthly caps reset at midnight on the first of the month. All period rollovers happen in the tenant timezone so the cap behavior matches the buyer’s business day.

What about oversells on concurrent traffic?

The atomic counter prevents oversells. When 20 concurrent pings all try to hit the same contract in the same millisecond, Lead Router uses a database-level atomic increment so only the first 20 minus (capRemaining) succeed. The rest see capRemaining = 0 and get dropped from the bid pool. No two pings can both push the counter past the cap.

Does a rejected sale count against the cap?

No. The cap increments only on a successful leadSale record. If a buyer returns a non-2xx on the full post, if the buyer rejects the lead, or if the ping wins but the source never posts the full lead, the cap counter does not move. Operators get the full budget they pay for.

Run Caps That Hold

Put your caps on atomic counters

Daily, weekly, monthly caps per contract. Atomic increments so no oversells under concurrent load. Timezone-aware rollovers so the buyer's business day matches the reset. Caps enforced during the ping so capped buyers never bid on leads they cannot take.

No credit card required. All features included from day one.