Credit Card Debt Relief Lead Webhook Integration

Quickstart

Three steps from zero to your first accepted lead.

1. Find your credentials

   You need two values — your key and your Partner ID, which are the same string. They're in the setup message from your team, and under Setup Integration in your Intro Partners account.

2. Send a test lead

   Send one lead with "test": true from your own server. It is validated exactly like a real lead, but never reaches outreach.

   cURLNode.jsPython

   Copy

   cURL

   curl -X POST https://api.tryintro.com/v1/leads \
     --max-time 10 \
     -H "Content-Type: application/json" \
     -H "X-Intro-Key: YOUR_KEY" \
     -d '{
       "referring_partner": "YOUR_PARTNER_ID",
       "pewc_provider": "trustedform",
       "pewc_token": "https://cert.trustedform.com/a1b2c3d4e5f6",
       "first_name": "John",
       "last_name": "Doe",
       "phone": "+13055551234",
       "email": "john.doe@example.com",
       "date_of_birth": "1985-04-12",
       "street_address": "120 Main St Apt 4",
       "city": "Miami",
       "state": "FL",
       "zip_code": "33101",
       "debt_amount": 25000,
       "debt_types": ["credit_card"],
       "test": true
     }'

   Node.js

   const res = await fetch("https://api.tryintro.com/v1/leads", {
     method: "POST",
     headers: {
       "Content-Type": "application/json",
       "X-Intro-Key": process.env.INTRO_KEY, // YOUR_KEY — keep it on the server
     },
     body: JSON.stringify({
       referring_partner: "YOUR_PARTNER_ID",
       pewc_provider: "trustedform",
       pewc_token: "https://cert.trustedform.com/a1b2c3d4e5f6",
       first_name: "John",
       last_name: "Doe",
       phone: "+13055551234",
       email: "john.doe@example.com",
       date_of_birth: "1985-04-12",
       street_address: "120 Main St Apt 4",
       city: "Miami",
       state: "FL",
       zip_code: "33101",
       debt_amount: 25000,
       debt_types: ["credit_card"],
       test: true,
     }),
     signal: AbortSignal.timeout(10_000),
   });
   
   const verdict = await res.json(); // { status: "accepted" | "rejected", ... }

   Python

   import os
   import requests
   
   res = requests.post(
       "https://api.tryintro.com/v1/leads",
       headers={"X-Intro-Key": os.environ["INTRO_KEY"]},  # YOUR_KEY
       json={
           "referring_partner": "YOUR_PARTNER_ID",
           "pewc_provider": "trustedform",
           "pewc_token": "https://cert.trustedform.com/a1b2c3d4e5f6",
           "first_name": "John",
           "last_name": "Doe",
           "phone": "+13055551234",
           "email": "john.doe@example.com",
           "date_of_birth": "1985-04-12",
           "street_address": "120 Main St Apt 4",
           "city": "Miami",
           "state": "FL",
           "zip_code": "33101",
           "debt_amount": 25000,
           "debt_types": ["credit_card"],
           "test": True,
       },
       timeout=10,
   )
   
   verdict = res.json()  # {"status": "accepted" | "rejected", ...}

   Set your client timeout at 10 seconds. The three samples above already do. A 3- or 5-second timeout is too short: it cuts off answers Intro is still deciding.

3. Watch it arrive, then go live

   The response tells you accepted or rejected right away, and the request shows up under Setup Integration within seconds. Once a test is accepted, send real leads without the flag.

Your credentials

Intro assigns your company one value. It is your API key and your Partner ID, and every request carries it twice: in the X-Intro-Key header and as referring_partner in the body.

Where to find them

Endpoint & request

All partners post to the same endpoint. Leads are attributed and routed by your partner identity value.

Example request headers

POST /v1/leads HTTP/1.1
Host: api.tryintro.com
Content-Type: application/json
X-Intro-Key: YOUR_KEY

Payload schema

The complete JSON body expected on each submission. All fields sit at the top level — there are no nested objects. Fields Intro does not recognise are ignored, but stored with the lead.

{
  "referring_partner": "YOUR_PARTNER_ID",

  "pewc_provider": "trustedform",
  "pewc_token": "https://cert.trustedform.com/a1b2c3d4e5f6",

  "first_name": "John",
  "last_name": "Doe",
  "phone": "+13055551234",
  "email": "john.doe@example.com",
  "date_of_birth": "1985-04-12",

  "street_address": "120 Main St Apt 4",
  "city": "Miami",
  "state": "FL",
  "zip_code": "33101",

  "debt_amount": 25000,
  "debt_types": ["credit_card"],

  "test": false
}

debt_amount is an integer in USD with a minimum of 10,000, and debt_types accepts credit_card, unsecured_personal_loan, medical_collections.

Field reference

Send fields as typed below — debt_amount as a number, debt_types as an array. Every field is required except test and ping_id: the lead's full name, phone, email, date of birth and street address, together with its debt, are what let Intro work the lead.

Consent certificate (PEWC)

Every submission must carry proof of the consumer's prior express written consent. Intro does not accept leads without it.

• The certificate must be claimable at the moment Intro ingests the lead. Fire the webhook in real time so the certificate is still retrievable.
• Intro stores and forwards the token as received. Intro performs no substantive audit of the certificate's contents; the validity of the underlying consent remains the Publisher's responsibility.
• One certificate per lead. Do not reuse a token across submissions.

Partner identity

Your Partner ID and your API key are the same value — one string, assigned to your company, in the setup message from your team, and under Setup Integration in your Intro Partners account. Send it in two places on every request:

• In the X-Intro-Key header — it authenticates the request and is what identifies you.
• As referring_partner in the body — Intro checks it against your key.

• Hard-code both values. Do not derive them from form input, and never let an end user populate them.
• Keep the key server-side. If it is ever exposed, tell us and we reissue it — only your traffic is affected.

The response

Intro answers every authenticated request synchronously, with the decision already made. There is no second, asynchronous verdict: what you get back is final.

Accepted

HTTP/1.1 200 OK

{
  "status": "accepted",
  "lead_id": "7a179944-3471-4e40-8d19-cae9d8af5e6a",
  "received_at": "2026-09-14T22:18:13.006Z"
}

Store lead_id. It is Intro's identifier for that lead and the reference for any later reconciliation.

Accepted, with fields missing

HTTP/1.1 200 OK

{
  "status": "accepted",
  "lead_id": "7a179944-3471-4e40-8d19-cae9d8af5e6a",
  "received_at": "2026-09-14T22:18:13.006Z",
  "missing_fields": ["date_of_birth", "zip_code"],
  "invalid_fields": ["email"]
}

When a required field was absent (missing_fields) or malformed (invalid_fields), the lead is still accepted today and the response names those fields. Each list appears only when it has something in it, so a complete lead gets the response above. Fix your mapping as soon as you see them: incomplete leads will be rejected later. A test lead reports them the same way.

Rejected

HTTP/1.1 200 OK

{
  "status": "rejected",
  "reason": "debt_below_minimum",
  "field": "debt_amount"
}

A rejection is returned as HTTP 200, not 4xx. A rejected lead is a business decision, not a protocol failure — the request was received and understood. Never retry a rejection. Retrying will return the same verdict and, for duplicate_lead, will keep returning it for 14 days.

A body that is not parseable JSON also comes back as 200 with reason: "malformed_json", so you never have to special-case a parse error into a different code path. Validation stops at the first rule that fails, so reason reports one problem at a time; field names the offending field, or is null when the problem is the payload as a whole.

HTTP status codes

Two-step ping/post

If your platform runs a classic ping/post flow — ask first, deliver second — Intro exposes a dedicated ping endpoint. You do not need it: a single post to the lead endpoint already returns the same verdict synchronously, and most partners use only that.

Use the ping when you want to know whether Intro will take a lead before you transmit the consumer's personal data, before you decide which buyer to route it to, or to avoid serving media against a lead Intro would decline.

Ping request

POST https://api.tryintro.com/v1/ping
X-Intro-Key: YOUR_KEY

{
  "referring_partner": "YOUR_PARTNER_ID",
  "phone": "+13055551234",
  "state": "FL",
  "debt_amount": 25000,
  "debt_types": ["credit_card"]
}

No pewc_token, and none of the consumer's personal data — no name, email, date of birth or address. The ping checks partner identity, phone format, state, debt amount, debt types, and the duplicate window. All five fields above are evaluated: a ping that omits debt_amount or state is rejected on that field, not treated as unknown. Give the ping the same 10-second client timeout as the post.

Ping response

{
  "status": "accepted",
  "ping_id": "a078caaa-dd9d-449a-8637-46f9f1e7084e",
  "received_at": "2026-09-14T23:06:54.025Z",
  "expires_at": "2026-09-14T23:36:54.424Z"
}

Then send the full lead to the lead endpoint as usual, adding ping_id so the two calls are linked in Intro's records. A rejection uses the same shape as the post — status, reason, field — drawn from the rejection reasons, minus the consent and personal-data reasons the ping does not evaluate.

Rejection reasons

The complete list. Every rejection returns exactly one of these in reason, with the matching field.

If you ever receive internal_validation_error, that is a fault on Intro's side, not in your payload. Report it to your technical contact; do not change your integration.

Duplicates, acceptance & billability

Intro deduplicates on phone number across all sources, not just yours. A number accepted from any partner within the previous 14 calendar days is rejected as duplicate_lead. Test submissions never count toward this window and never create one.

An accepted lead is a worked lead: it enters Intro's CRM and outreach immediately. Because the verdict is synchronous and final, accepted leads are the billable set — there is no later reconciliation that removes leads from it. Rejected leads are not contacted, not worked, and not billable, and you know which ones they are the moment you send them.

Suppression & consumer requests

When a consumer opts out with Intro by voice or SMS, Intro pushes the suppression to the partner within 24 hours. The partner supplies a destination during onboarding — an HTTPS endpoint that accepts a JSON POST, or an email address for a daily file.

{
  "referring_partner": "YOUR_PARTNER_ID",
  "phone": "+13055551234",
  "opted_out_at": "2026-09-15T18:04:00Z"
}

The partner applies these suppressions in its own systems and does not re-submit a suppressed consumer. Consumer privacy requests (access, correction or deletion) that reach the partner and concern a lead sent to Intro must be forwarded to Intro's privacy contact. Intro deletes or anonymises the consumer's personal data in its operating systems within three business days. Consent certificates and non-audio evidence are retained regardless, as required for legal defence.

How Intro handles the lead

The partner does not configure any of the following. It is stated so the partner knows what happens to a lead after delivery and can answer consumer questions.

Onboarding checklist

Intro provides your key and your referring_partner ID — in the setup message from your team, and under Setup Integration in your Intro Partners account. The endpoint URLs are in this guide.

Go-live check

Before sending real leads, send one test: the same request with "test": true, your partner ID, a live consent certificate and a phone number you control. Intro validates it exactly like a real lead — same rules, same rejection reasons — and answers without sending it to outreach and without counting it toward the duplicate window.

HTTP/1.1 200 OK

{
  "status": "accepted",
  "test": true,
  "lead_id": "4c6604d3-4127-4bab-bb95-1243f9ea3169",
  "received_at": "2026-09-14T22:18:17.171Z"
}

"status": "accepted" on the test, with no missing_fields or invalid_fields in the response, is your go-live: from then on, send real leads without the flag. A "status": "rejected" tells you exactly which rule to fix before you go live — that is the point of the test. You can send as many tests as you need while building; use them to walk your integration through each rejection reason and confirm your error handling.

Watch your tests arrive