How Consent Verification APIs Work: A Technical Guide for Lead Buyers and Sellers

If you work in lead generation, you have probably heard that consent verification is table stakes for TCPA compliance in 2026. But what does a consent verification API actually do under the hood? How does it fit into your existing lead flow? And what should you expect from the data it returns?

This guide breaks down the mechanics of consent verification APIs for developers and technical PMs who need to evaluate, integrate, or build around them.

What a consent verification API does

A consent verification API provides a programmatic way to answer one question: did this consumer give valid, documented consent to be contacted?

At a minimum, the API accepts an identifier (phone number, email, or both) and returns a structured response indicating whether a matching consent record exists, along with the evidence that supports it.

The typical data flow looks like this:

1. A consumer fills out a form on a landing page
2. A consent capture system records the session and generates a certificate at the time of submission
3. The certificate and associated evidence are stored immutably
4. Later, when someone wants to verify that consent exists, they query the API with the consumer’s contact information
5. The API returns the consent record, including metadata and links to the underlying evidence

The API sits between consent capture (which happens on the publisher’s landing page) and consent consumption (which happens when a lead buyer dials or texts the consumer).

The integration architecture

There are two sides to a consent verification integration: the capture side and the query side.

Capture side (for publishers and lead sellers)

The capture side is typically a lightweight JavaScript snippet added to your landing page. It handles:

• Session recording of the consumer’s interaction with the form
• Disclosure capture of the exact TCPA consent language displayed
• Form data extraction of the fields the consumer submitted
• Certificate generation triggered at the moment of form submission

With eConsent, this is a single script tag:

<script src="https://cdn.econsent.org/web.min.js"
        data-site="YOUR_SITE_ID"></script>

<form data-econsent="true">
  <!-- your existing form fields -->
</form>

No backend changes. No build step. The script observes the form, captures the session, and transmits the data to the consent verification platform on submission.

Query side (for lead buyers and dialers)

The query side is a REST API that your systems call before dialing or purchasing a lead. A typical integration point is:

• In your lead intake pipeline, immediately after receiving a lead from a seller
• In your dialer’s pre-call workflow, as a check before the call is placed
• In your CRM, as a verification step when a lead record is created

The query is straightforward. Here is an example using eConsent’s Retain API:

curl -X POST https://api.econsent.org/api/verify \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "phone": "+15551234567",
    "match_type": "exact"
  }'

What the API returns

A consent verification API response should give you everything you need to assess the validity of a consent record. Here is what to expect from a well-designed response:

Match status

The primary field indicates whether a matching consent record was found:

• verified — an exact or partial match was found
• not_found — no matching consent record exists for the given identifier
• expired — a record exists but falls outside the valid consent window

Match type

How the identifier was matched against stored records:

• exact — the phone number or email matches a certificate exactly
• partial — a fuzzy match on name, address, or other secondary fields, returned with a confidence score

Certificate data

The core consent evidence:

{
  "status": "verified",
  "match": "exact",
  "certificate_id": "cert_8f3a2b1c9d4e...",
  "consented_at": "2026-03-28T14:32:01Z",
  "disclosure_text": "I agree to be contacted by Example Corp...",
  "recording_url": "https://app.econsent.org/recordings/...",
  "snapshot_url": "https://app.econsent.org/snapshots/...",
  "ip_address": "203.0.113.42",
  "form_data": {
    "first_name": "Jane",
    "last_name": "Doe",
    "phone": "+15551234567",
    "email": "jane@example.com"
  },
  "hash": "sha256:a4f8c2e9b7d1..."
}

Key fields to pay attention to:

• disclosure_text — the exact TCPA language the consumer saw and agreed to. This is critical for one-to-one consent validation. Check that your company name appears in this text.
• consented_at — the ISO 8601 timestamp of when consent was captured. Use this to determine if consent is still within your acceptable window.
• recording_url — a link to the session recording (and/or MP4 video) showing the consumer’s interaction with the consent form.
• hash — the SHA-256 hash of the certificate, allowing you to verify that the record has not been tampered with.

How to validate consent before buying a lead

If you are a lead buyer, here is a practical workflow for integrating consent verification into your lead intake process:

Step 1: Receive the lead

Your lead seller sends you a lead via ping-post, API, or file delivery. The lead includes standard fields: name, phone, email, and whatever vertical-specific data applies.

Step 2: Query the consent verification API

Before accepting or purchasing the lead, query the API with the consumer’s phone number:

import requests

response = requests.post(
    "https://api.econsent.org/api/verify",
    headers={
        "Authorization": "Bearer YOUR_API_KEY",
        "Content-Type": "application/json"
    },
    json={
        "phone": lead["phone"],
        "match_type": "exact"
    }
)

result = response.json()

Step 3: Evaluate the response

Apply your business rules to the response:

if result["status"] == "verified":
    # Check that consent is recent enough
    consent_age = now - parse(result["consented_at"])
    if consent_age > timedelta(days=90):
        reject_lead("consent_too_old")

    # Check that your company is named in the disclosure
    if "Your Company Name" not in result["disclosure_text"]:
        reject_lead("not_named_in_disclosure")

    # Consent is valid -- accept the lead
    accept_lead(lead, certificate_id=result["certificate_id"])

elif result["status"] == "not_found":
    reject_lead("no_consent_record")

Step 4: Store the certificate reference

When you accept a lead, store the certificate_id alongside the lead record in your CRM or database. If a TCPA claim is filed against this lead, you can retrieve the full certificate and evidence package using this ID.

Integration patterns

Real-time ping-post validation

In a ping-post lead distribution model, insert the consent verification query between the ping and the post. This adds minimal latency (typically under 200ms) and ensures you never purchase a lead without verified consent.

Publisher form submission
    --> Consent capture (automatic)
    --> Ping to lead buyer
    --> Buyer queries consent API
    --> If verified: post (accept lead)
    --> If not verified: reject

Batch verification

If you receive leads in batches (file drops, scheduled transfers), run verification against the full batch before importing into your dialing system. Flag any leads without verified consent for manual review or rejection.

Dialer integration

If your dialer supports pre-call webhooks or API checks, insert consent verification as a gate. The call should not be placed unless the verification API returns a verified status with your company named in the disclosure text.

What to look for in a consent verification API

When evaluating platforms, assess these technical characteristics:

• Latency. The API should respond in under 200ms for real-time lead flow integration. Anything slower creates friction in ping-post environments.
• Uptime. Look for 99.9%+ availability with published status pages. Your lead flow depends on this.
• Authentication. API key-based auth is standard. Look for key rotation support and the ability to create scoped keys for different environments or partners.
• Match flexibility. Support for both exact and fuzzy matching is important. Phone numbers are the primary identifier, but email and name-based lookups provide fallback options.
• Webhook support. The ability to receive webhooks when new certificates are created lets you build event-driven workflows rather than polling.
• Retention period. Consent records should be retained for at least five years. TCPA claims can surface long after the original consent event.

Common integration pitfalls

A few mistakes we see regularly:

Not checking the disclosure text. A verified status means consent exists, but it does not mean the consumer consented to be contacted by your company specifically. Always parse the disclosure_text field and confirm your company is named.

Ignoring consent age. Consent is not permanent. A lead generated six months ago with valid consent at the time may no longer represent current consumer intent. Define and enforce a maximum consent age in your integration logic.

Treating verification as optional. If consent verification is a soft check that can be bypassed by an operations team override, it will be bypassed. Make it a hard gate in your lead acceptance workflow.

Not storing the certificate reference. The whole point of verification is having evidence when you need it. If you verify consent but do not store the certificate ID, you will have to re-query the API later and hope the record still matches.

Getting started

If you are ready to integrate consent verification into your lead flow, the process is straightforward:

1. Sign up at app.econsent.org/register and generate an API key
2. Add the capture script to your landing pages (if you are a publisher)
3. Integrate the verification API into your lead intake pipeline (if you are a buyer)
4. Review the full API documentation at econsent.org/docs for endpoint details, error codes, and rate limits

The goal is simple: make consent verification an automated, non-negotiable step in your lead flow. Every lead that enters your system should have a verifiable consent record attached to it.

eConsent’s Retain API provides real-time consent verification with sub-200ms response times. View the docs or start for free to integrate consent verification into your lead flow today.