Partner Certificates

When publishers sell leads to buyers, the buyer needs proof of consent. Partner Certificates let publishers share cryptographically signed consent certificates with lead buyers through eConsent, creating an auditable chain of custody.

How it works

Publisher (Company A)              Buyer (Company B)
─────────────────────              ──────────────────
1. Captures consent
2. Certificate generated
3. Shares certificate ──────────►  4. Claims certificate
                                   5. Validates consent language
                                   6. Views evidence package

The publisher generates a claim token (clm_xxx) and passes it to the buyer with the lead data. The buyer redeems the token to claim the certificate into their account.

Key concepts

Property Partners

Ongoing relationships between a publisher and buyer. When configured, certificates can be auto-shared from a property to a specific buyer.

Claim Tokens

One-time use tokens that grant access to a specific certificate. Tokens expire after 90 days. Once claimed, the certificate is permanently associated with the buyer’s account.

Consent Language Rules

Buyer-defined validation rules that check whether the certificate’s consent language contains required phrases (e.g., the buyer’s company name, ATDS disclosure).

Compliance Scoring

Automated validation results: 100% = all required phrases found, partial = some missing, failed = most missing.

Chain of Custody

Every action is logged: created, signed, shared, claimed, verified, accessed. This immutable audit trail is critical evidence in litigation.

---

API Reference

All endpoints are under /certificate-sharing/. Authenticated endpoints require a valid session cookie.

Partner Management

Add a distribution partner

POST /certificate-sharing/partners

Request body:

{
  "property_id": "67fa8d40a96f513ae019c85c",
  "partner_company_id": "68a1b2c3d4e5f6a7b8c9d0e1",
  "access_level": "claim",
  "auto_share": false
}

Response:

{
  "id": 1,
  "property_id": "67fa8d40a96f513ae019c85c",
  "publisher_company_id": "67fa8acb61f623d0e200ec4d",
  "partner_company_id": "68a1b2c3d4e5f6a7b8c9d0e1",
  "access_level": "claim",
  "auto_share": false,
  "status": "active",
  "created_at": "2026-04-18T12:00:00.000Z"
}

List partners

GET /certificate-sharing/partners

Returns all active partners for the authenticated user’s company.

Revoke a partner

DELETE /certificate-sharing/partners/:id

Soft-deletes the partnership (sets status to revoked). Existing claims are not affected.

---

Certificate Sharing

Share a certificate

POST /certificate-sharing/certificates/:certificateId/share

Request body:

{
  "target_company_id": "68a1b2c3d4e5f6a7b8c9d0e1"
}

target_company_id is optional. If omitted, generates an open claim token that any buyer can use.

Response:

{
  "claim_token": "clm_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3",
  "claim_url": "https://app.econsent.org/certificate-sharing/certificates/claim/clm_a1b2c3...",
  "expires_at": "2026-07-17T12:00:00.000Z"
}

Tip

Pass the claim_token or claim_url to your buyer alongside the lead data — via ping/post, API callback, or any existing delivery mechanism.

Batch share

POST /certificate-sharing/certificates/batch-share

Request body:

{
  "certificate_ids": ["cert_001", "cert_002", "cert_003"],
  "target_company_id": "68a1b2c3d4e5f6a7b8c9d0e1"
}

Returns an array of { certificate_id, claim_token, claim_url } for each certificate.

---

Certificate Claiming

Preview a certificate (public, no auth)

GET /certificate-sharing/certificates/claim/:token

Returns a summary without PII — safe to open in a browser before claiming.

Response:

{
  "certificate_id": "EC-9ea0cfa5-...",
  "publisher_name": "LeadGen Co",
  "property_domain": "forms.leadgen.com",
  "consent_captured_at": "2026-04-17T11:00:00.000Z",
  "has_recording": true,
  "status": "pending",
  "expires_at": "2026-07-17T12:00:00.000Z"
}

Claim a certificate

POST /certificate-sharing/certificates/claim/:token

Claims the certificate and runs consent language validation against the buyer’s rules.

Response:

{
  "claim_id": 42,
  "certificate_id": "EC-9ea0cfa5-...",
  "status": "claimed",
  "claimed_at": "2026-04-18T14:30:00.000Z",
  "compliance": {
    "score": 75,
    "matched": ["Acme Insurance", "autodialer"],
    "missing": ["consent is not required as a condition of purchase"],
    "status": "warn"
  }
}

---

Partner Certificates (Buyer)

List claimed certificates

GET /certificate-sharing/partner-certificates

Query parameters:

Param	Type	Description
page	number	Page number (default: 1)
limit	number	Results per page (default: 25, max: 100)
status	string	Filter by status: pending, claimed, flagged, rejected

Full evidence package

GET /certificate-sharing/partner-certificates/:claimId/evidence

Returns the complete evidence for a claimed certificate: consent language, HMAC signature, timestamps, geo data, compliance results, and a link to the session replay.

---

Consent Language Rules

Create a rule

POST /certificate-sharing/consent-rules

Request body:

{
  "rule_name": "TCPA Express Consent",
  "required_phrases": [
    "Acme Insurance",
    "autodialer",
    "consent is not required as a condition of purchase"
  ],
  "mode": "warn"
}

Modes:

• warn — Flag non-compliant certificates but allow claiming
• reject — Auto-reject certificates that don’t meet requirements

List rules

GET /certificate-sharing/consent-rules

Update a rule

PUT /certificate-sharing/consent-rules/:id

Delete a rule

DELETE /certificate-sharing/consent-rules/:id

---

Consent language validation

When a certificate is claimed, eConsent validates the captured consent language against the buyer’s rules:

1. Extract the consent text from the certificate
2. For each rule, check if all required_phrases appear in the text (case-insensitive)
3. Check for forbidden_phrases if configured
4. Calculate a compliance score: matched / total_required * 100
5. Apply the rule’s mode (warn or reject)
6. Look up the consumer’s state from session geo data for state-specific checks

Individual phrases vs full consent text

Buyers can create rules in two ways:

Individual phrases — Add specific terms one at a time. Good for checking key compliance elements like company name, ATDS disclosure, or “not a condition” language.

Full consent text — Paste the entire required consent paragraph. eConsent breaks it into sentences and validates each one. Good when your legal team provides a specific disclosure block.

Caution

Consent language validation is an automated compliance check, not legal advice. It verifies text presence using string matching. Always consult qualified legal counsel for TCPA compliance decisions.

---

Chain of custody

Every certificate maintains an immutable audit log:

Event	When logged	Details captured
created	Certificate generated	Publisher, property, timestamp, IP
signed	HMAC signature applied	Signature hash, algorithm
shared	Publisher shares with buyer	Share token, target company
claimed	Buyer claims certificate	Claiming company, IP, timestamp
compliance_checked	Validation runs	Score, matched/missing phrases
accessed_evidence	Buyer views evidence	Accessor ID, timestamp

This audit trail provides verifiable proof of when consent evidence was obtained and by whom — critical for defending against TCPA litigation.

---

Best practices

For publishers:

• Share certificates promptly — claim tokens expire after 90 days
• Use auto-share for exclusive buyer relationships to eliminate manual sharing
• Ensure your consent language includes your buyer’s company name if they require one-to-one consent

For buyers:

• Set up consent rules before claiming certificates — validation runs automatically on claim
• Use “warn” mode initially to understand your compliance posture, then switch to “reject” once publishers have updated their forms
• Retain claimed certificates permanently — they serve as your litigation defense
• Use the batch verify API for high-volume lead purchasing