Kaliper Documentation
Ping processing pipeline
Every ping that arrives at the Kaliper Relay passes through a fixed pipeline before reaching a buyer.
The pipeline
1. Source restriction check
The Relay checks entity-level restrictions:
Is this buyer restricted by the publisher?
Is this target restricted by the publisher?
Is this publisher restricted by the buyer or target?
Is this Sub-ID restricted by the publisher, campaign, buyer, or target?
Does the phone number fail validation, and is invalid phone restricted on the buyer or target?
Does the ZIP fail validation, and is invalid ZIP restricted — only when ZIP enrichment is off. When enrichment is on, the ZIP check is deferred until after enrichment (see stage 4).
If any restriction matches, the ping is blocked here and never proceeds further. No ping record is created for blocked-at-restriction pings.
2. Deduplication check
The Relay computes the dedup key from the ping based on the deduplication rule configured on the buyer or target:
Rule | Key |
|---|---|
Phone | Phone number |
Phone + ZIP | Phone number + ZIP code |
Pass Through | Source ID — each ping treated as unique |
The key is checked against a 15-second sliding window. Two paths from here:
Original ping — key not seen before. The Relay registers the key and continues to stage 4.
Duplicate ping — key already exists from a previous ping. The duplicate waits for the original to finish, then the same response is returned to the platform. The buyer is not called again. Duplicate pings do not create a separate ping record.
3. ZIP enrichment
For original pings only. If ZIP enrichment is enabled for the org, the Relay attempts to resolve a ZIP from the caller's phone number and attaches it to the ping. The enriched ZIP is what gets sent to the buyer; the original ZIP is preserved separately.
After enrichment, if the ZIP is still invalid and the buyer or target has Restrict Invalid ZIP enabled, the ping is blocked here with a source restriction. No ping record is created for these blocks.
4. Attribute filter
Caller profile attributes (age, state, income, etc.) are evaluated against any attribute filters configured on the publisher, campaign, buyer, or target. If the ping fails any filter condition, it receives Suppressed status and is not dispatched.
5. Audience and Dataset suppression
The ping's phone number, ZIP, publisher, campaign, buyer, and target are checked against all active Audiences and Datasets assigned to these entities. If any suppression rule matches, the ping receives Suppressed status and is not dispatched.
Important: Attribute filters (stage 5) run before Audience suppression (stage 6). Both produce the same Suppressedstatus — the diagnostic data in the ping detail panel indicates which specific rule triggered it.
6. Cap check
Volume caps are evaluated for the publisher, buyer, and target. All three are checked independently — a ping can be blocked by the publisher's cap even if the target's cap has not been reached.
If any cap is exceeded, the ping receives Capped status and is not dispatched.
7. Payload enrichment
If payload enrichment is enabled on this target and a body template is configured, the Relay resolves caller profile attribute placeholders in the template and deep-merges the result into the original request body. This is the final form of the payload sent to the buyer.
8. Buyer dispatch
The Relay sends the HTTP request to the buyer's API endpoint. The timeout is determined by the target's configured timeout, capped by any active auction timeout on the campaign.
For Fixed targets, no HTTP request is made — the pre-configured bid is used directly.
For Static targets, no HTTP request is made — a static response is returned immediately.
9. Response parsing and classification
The buyer's response is parsed against the org's configured parse rules to determine the outcome:
Outcome | Status assigned |
|---|---|
Bid received within auction window | Accepted |
Bid received after auction window closed | Accepted — flagged as late; shown with red latency in the Pings page |
Buyer responded with rejection | No Coverage |
Buyer's rate limiter blocked the request | Rate Limited |
Network or system error | Error |
Response timed out | Error |
No parse rule matched the response | Unknown |
10. Auction result
When auction mode is active on the publisher, the Relay publishes the bid to the publisher's auction channel so competing pings from the same call can resolve the highest bid.
11. Async logging
The ping record (status, bid, request, response, diagnostic data) is queued for async storage. The Relay returns the response to the publisher before the record is written.
Ping statuses
Status | Assigned at stage | Meaning |
|---|---|---|
Accepted | 10 — Response parsing | Bid received and call routed |
No Coverage | 10 — Response parsing | Buyer returned a rejection |
Rate Limited | 10 — Response parsing | Buyer's rate limiter blocked the ping |
Capped | 7 — Cap check | A volume cap was reached |
Suppressed | 5 or 6 — Attribute filter or Audience/Dataset | A suppression rule matched |
Error | 10 — Response parsing | Network or system error during buyer request |
Unknown | 10 — Response parsing | The buyer was contacted but no parse rule matched the response. Check your parse rules configuration. |
Duplicate | 2 — Deduplication check | Ping identified as a dedup duplicate — the cached response from the original ping was returned; the buyer was not called again |
© 2026 A-Launch. All rights reserved.