TCPA compliance for ping/post lead delivery
TCPA compliance for ping/post lead delivery works the same way as for any other lead sale: real-time speed does not change the consent requirements. The consent record captured on the seller's form has to travel with the post to the winning buyer, so that buyer can show what the consumer agreed to. This is educational content, not legal advice.
Real-time lead delivery changes the speed of transactions, but not the consent requirements. Here's how TCPA obligations apply throughout the ping/post environment and what documentation must travel with every lead.
Educational Content Only: This is educational content, not legal advice. Consult a qualified attorney for compliance guidance specific to your operations.
How TCPA consent works in ping/post environments
Ping/postPing/postA real-time selling method in which a lead is pinged to buyers with partial data, buyers bid, and the winning bidder receives the full lead by post. Glossary is a two-step real-time delivery mechanism used widely in lead generation: a lightweight "ping" containing key lead attributes is sent to one or more buyer endpoints for evaluation and pricing, and if accepted, a full "post" containing the complete lead record is sent to the winning buyer's system. The process typically completes in under a second. This architecture is designed to maximize lead value by routing supply to the highest-demand buyer in real time, but speed of delivery does not modify consent obligations.
Prior express written consentPrior express written consentUnder the TCPA, a written agreement signed by the consumer (an electronic signature counts) that clearly authorizes a seller to make telemarketing calls or texts using an autodialer or a prerecorded or artificial voice to a stated number. Glossary must be in place before the lead is captured, not before it's delivered. The consumer's consent authorizes the buyer's subsequent contact, and that authorization must be valid for the type of contact the buyer intends to make. If the buyer will use an autodialer, the consent must specifically authorize autodialed contact. If the buyer will send prerecorded voice messages, the consent must authorize prerecorded voice. The delivery method (batch, real-time, API, CSV) is irrelevant to what the consent must say.
Documentation requirements in ping/post environments flow from this reality. Because the consent is captured by the seller before the buyer ever sees the lead, the seller must transmit consent documentation alongside the lead data. Practically, this means the post payload should include structured fields for: the exact consent language text shown to the consumer at the time of submission, the UTC timestamp of form submission, the consumer's IP address at the time of submission, and the URL of the form page where consent was captured. Some buyers also require the specific phone number as entered by the consumer, to confirm the consent covers the number they intend to call.
The real-time nature of ping/post creates a specific compliance risk that batch deliveryBatch deliverySending leads to a buyer in scheduled groups, such as a file or a periodic upload, instead of one at a time as they are captured. Glossary does not: because acceptance decisions are made algorithmically in milliseconds, buyers are not manually reviewing consent documentation before accepting each lead. Non-compliant leads can flow through automated acceptance filters without detection. Compliance risk concentrates at the discovery phase, when a consumer complaint triggers a consent record lookup weeks or months after the lead was delivered. At that moment, whatever documentation is in your records is what you have to work with.
One-to-one consent vs. shared consent
The FCC's one-to-one consentOne-to-one consentAn FCC rule adopted in 2023 that would have limited each prior express written consent to a single seller. Glossary rule, adopted in December 2023, would have fundamentally restructured the consent architecture that most multi-buyer ping/post operations had relied on for years. The prior industry practice (using "shared consent" language that authorized contact from a broad category of businesses ("solar energy providers," "home improvement contractors," "insurance companies") allowed a single consumer consent to satisfy multiple buyers simultaneously, enabling true multi-buyer ping/post routing from a single lead.
The rule would have eliminated that approach by requiring consent to identify the specific entity making the contact. It never took effect: the Eleventh Circuit vacated it on January 24, 2025 (Insurance Marketing Coalition v. FCC), and the FCC restored its prior definition of prior express written consent, effective August 29, 2025. That definition still requires consent that clearly authorizes the seller to call, so a consumer's consent to be contacted by Company A does not automatically authorize Company B. In a ping/post context where the buyer isn't known at the time of consent capture, because the lead will be routed in real time to whichever buyer wins the auction, whether the consent language clearly covers the buyers who may call remains the central question.
Operators whose buyers require seller-specific consent generally take one of two approaches. The first is exclusive routing: capture consent that names a specific buyer or a small set of named buyers, route each lead to the matching buyer, and don't distribute beyond the scope of the consent. This is the cleanest compliance posture but limits multi-buyer optimization. The second approach is full buyer disclosure: if you intend to distribute leads to multiple buyers, list all potential buyers by name in the consent language on your form. This is operationally complex (it requires maintaining current buyer lists in your consent language and updating forms when buyer relationships change), but it preserves multi-buyer distribution within compliance bounds.
Operators running shared-consent models with broad category language should still review them against each buyer's contract. While litigation timelines mean that enforcement is often retroactive, buyer contract audits operate in real time. Buyers that keep seller-specific consent as a contractual requirement audit supplierSupplierAny company that provides leads to a buyer, whether it generates them itself or brokers them from publishers. Glossary forms, and broad category language may trigger contract termination under those agreements.
What the receiving buyer needs
A buyer's TCPA exposure is directly tied to the quality of the consent documentation they received from their lead supplier. This alignment of interests explains why buyers have steadily elevated their consent documentation requirements over the past several years, not as bureaucratic box-checking, but as genuine risk management. When a buyer's contact attempt generates a consumer complaint, the first question their legal team asks is: "What consent documentation do we have?"
The minimum documentation buyers require includes: the exact consent language shown to the consumer (the verbatim text, not a paraphrase or description), proof of affirmative form submission in the form of a timestamp, the form URL, and the consumer's IP address. This documentation is used in two scenarios: when a consumer disputes that they consented, and when a plaintiff's attorney demands consent records in discovery. In both cases, the documentation needs to be specific enough to tie a particular lead record to a particular form submission event with particular consent language.
Sophisticated buyers increasingly require more than the minimum. Archived form screenshots (images showing how the consent form appeared to the consumer at the time of capture, including the consent language, the form layout, and any disclosures) have become a standard requirement in high-value verticals. These screenshots serve as evidence that the consent language was not only present in your database but actually visible to the consumer in a clear and conspicuous format on the form. Some buyers require a publicly accessible URL where they can retrieve these archived screenshots on demand, often with response time SLAs written into supplier contracts.
Buyer contracts for ping/post relationships typically include consent warranties (seller represents that all leads are generated with TCPA-compliant consent), indemnification clauses (seller indemnifies buyer for TCPA claims arising from consent defects), and documentation delivery requirements (seller provides consent records in delivery payload, not just on request). Understanding these terms before signing matters, and understanding them shapes what compliance infrastructure you need to operate.
How real-time delivery affects the compliance chain
The speed pressure inherent in real-time lead delivery creates systematic incentives for compliance shortcuts that lead generators should actively resist. When a landing page is converting and leads are flowing in real time, there is constant pressure to minimize friction between form submission and lead delivery, and compliance documentation requirements can feel like friction. But the documentation that "slows down" the process is exactly the documentation that protects you when a lead is disputed six months later.
Buyers run automated acceptance filters that make decisions in milliseconds based on data fields in the ping payload: project type, geography, phone number validity, consent timestamp. These filters don't evaluate the quality of consent language; they evaluate the presence of consent data. A lead with a timestamp but defective consent language may pass through automated filters just as easily as a fully compliant lead. The compliance gap is only discovered at dispute resolution time, which is too late to retroactively fix the documentation.
The solution is to automate compliance rather than manually review it. Every lead capture event should automatically log all required consent fields to the database with the lead record as the primary key. The post payload should be generated from these structured fields automatically, not assembled manually per lead. Form version management should track which consent language was live at each point in time, automatically associating the current version with each lead captured. These processes run at machine speed and add no meaningful latency to real-time delivery.
Compliance risk in ping/post concentrates at the discovery phase, when a consumer complaint or class action lawsuit triggers a subpoena for consent records. At that moment, you need to be able to retrieve a specific lead's complete consent documentation from your systems quickly and completely. If your records are stored in a way that makes individual record retrieval difficult (aggregate logs, periodic CSV exports, manual records), your compliance posture is weaker than it appears, regardless of how carefully you wrote your consent language.
Seller documentation requirements
For every lead processed through a ping/post delivery chain, the seller should maintain: the exact consent form HTML archived with a content hash and effective timestamp (so you can prove what the form contained on any given date), the consumer's IP address and UTC timestamp of form submission, the URL of the form page, the lead source identifier (campaign, ad, page variant), and any third-party vendor identifiers if the lead was sourced through a network or media partner. These fields should be stored as part of the lead record, not in separate logs that require manual correlation.
Record retention for TCPA purposes should cover at minimum five years, reflecting the four-year federal statute of limitations for TCPA claims plus a buffer for cases filed near the limitation deadline. For verticals with longer downstream case timelines, personal injury and other legal leads in particular, consider extending retention to seven years. The storage cost of consent records is trivial compared to the litigation cost of being unable to produce them.
High-volume best practice has evolved toward real-time screenshot capture of the consent form at each submission event, stored with the lead record and accessible via a retrieval URL that can be included in the delivery payload. This approach creates the strongest possible documentation: not just the text of the consent language, but a visual representation of exactly what the consumer saw when they submitted the form. Plaintiff's attorneys and buyer compliance teams find this documentation format nearly indefensible to challenge, because it's a direct record of the consumer-facing consent experience rather than a database field populated by back-end code.
Sellers who invest in solid documentation infrastructure create a durable competitive advantage with quality buyers. As compliance requirements become more standardized and enforcement more active, the sellers who can produce complete, accurate, and instantly retrievable consent records become the preferred suppliers for buyers who want to minimize their own risk exposure. Compliance infrastructure is a business investment, not just a legal obligation.
Related resources
Is ping/post TCPA compliant?
Ping/post is a delivery mechanism, not a compliance status. Whether a ping/post lead is TCPA compliant depends entirely on the consent captured at the time of lead generation. Real-time delivery doesn't create or fix compliance issues: it simply moves data faster. Consent requirements are identical whether you're delivering via batch CSV or real-time API.
Who is responsible for consent in ping/post?
Both parties carry obligations. The seller is responsible for capturing valid consent and providing accurate documentation. The buyer is responsible for verifying the consent covers the type of contact they intend to make. Ping/post contracts typically include consent warranties from the seller and indemnification clauses: sellers can face chargebacks and legal exposure if their documentation is found defective after the lead is delivered.
What consent documentation is needed for ping/post?
At minimum: the exact consent language shown to the consumer, the form URL, the consumer's IP address, and the UTC timestamp of form submission. Most buyers also require the specific phone number entered, the source campaign identifier, and on-demand retrieval capability for specific leads. Documentation should travel with the lead in the post payload, not be maintained separately and retrieved only on request.
Can I sell leads via ping/post without signed consent?
No. An electronic "signature", an affirmative click of a submit button with clear consent language, is required. You cannot sell leads to buyers using autodialers or prerecorded messages without prior express written consent. Attempting to do so creates liability for both parties. Most buyers will reject leads or terminate accounts if non-compliant consent is discovered during an audit.
Ready to deliver compliant ping/post leads?
Tell us your delivery setup and consent architecture: we'll configure integration with buyers who require documented TCPA-compliant supply.
Discuss Your Ping/Post SetupBuying leads instead? Become a buyer