Caps and deduplication

Caps and deduplication are two mechanisms the Relay uses to control how many pings reach your buyers and how repeated pings are handled. Both are configured per entity in the Relay settings tab of any Publisher, Buyer, or Target detail window.

Volume caps

A volume cap sets a hard limit on how many pings an entity can accept in a given time window. When the cap is reached, any additional pings receive the Capped status and are not dispatched to buyers.

Cap types

You can set any combination of cap types on the same entity. All three limits are evaluated independently — a ping is blocked if any one of them is reached.

Where to set caps

Caps are available on Publishers, Buyers, and Targets. They are configured in the Cap and restrict block in each entity's Relay settings tab.

• Publisher caps apply to all pings originating from that publisher, regardless of which buyer or target receives them.

• Buyer caps apply to all pings dispatched to that buyer across all its targets.

• Target caps apply to pings dispatched to that specific target only.

When both a Buyer cap and a Target cap are set, both are enforced independently. A ping can be blocked by the Buyer cap even if the Target's cap has not been reached.

Visual indicators

In the Ping Control table, the Capped column counter turns red when the count meets or exceeds the configured cap.

Throttled vs Capped

Throttling is related to caps but distinct:

• Capped — a hard count limit was reached (daily, hourly, or minute). Pings are blocked until the window resets.

• Throttled — a rate-based limiter is slowing down traffic. Pings are blocked based on the rate of incoming traffic, not a specific count.

Both statuses appear separately in the Pings distribution bar on the Ping Control page. In the Latest Pings tab, both are included together under the Capped filter chip.

Deduplication

When an identical ping has already been processed recently, the Relay returns a cached copy of the original response without re-contacting the buyer.

Dedup rules

Where to set the dedup rule

The dedup rule is set on a Buyer or a Target. Targets inherit the rule from their Buyer by default.

• If a Target has no rule set, it shows (inherited) next to the Buyer's rule name.

• If a Target has a rule explicitly set to the default value (Pass Through), it shows (default) to distinguish from an inherited rule.

To override the dedup rule for a specific target without changing it for the buyer's other targets, set the rule directly on that target.

Cached responses and duplicate pings

When a ping is deduplicated, the Relay returns the cached response from the original ping — including the original bid — without contacting the buyer. Duplicate pings do not create a separate ping record; they are tracked against the original ping.

Duplicate pings can still generate revenue if the cached response included a winning bid. This revenue is tracked separately:

• Revenue From Dup. Pings — stat card on the Ping Control page showing revenue attributed to duplicate ping responses.

• Calls from Dup — count of calls that originated from a duplicate ping response.

Both are visible in the dashboard and in the table's column set.

Limitations

• Caps reset on the Relay clock, not the call tracking platform clock. If your call tracking platform uses a different timezone or midnight reset, cap counts may diverge slightly between systems.

• There is no carry-forward. When a cap window resets, the counter starts at zero — unused capacity from the previous window does not roll over.

• Dedup window is fixed at 15 seconds. The deduplication TTL cannot be adjusted per buyer or target.