createLeadMatch
Bypass automatic matching to manually create a lead-member match. Use for data migrations or override scenarios; verify pair uniqueness to avoid double billing.
Instructions
Create a lead match - Create a new leadmatch record. Writes live data.
Use when: manually creating a lead↔member match BYPASSING BD's auto-matching. Rarely needed - usually matchLead handles this automatically. Use for data migrations, manual override scenarios, or replaying matches from another system.
Required: lead_id, user_id, lead_status, match_price, lead_token, lead_matched_by.
Pre-check before create (PAIR uniqueness): BD does NOT enforce uniqueness on the (lead_id, user_id) pair. Matching the same lead to the same member twice creates two match rows - the member gets double-billed (if the match charges credits), both rows appear in the member's inbox, and reporting double-counts the match. Filter-find pattern (single-field server filter + client-side intersect): call listLeadMatches property=lead_id property_value=<proposed lead_id> property_operator== to narrow to all matches for that lead, then CLIENT-SIDE filter the returned rows to those where user_id=<proposed user_id>. Zero results after the client-side step = pair free; >=1 = already matched. If the pair already exists: reuse via updateLeadMatch (e.g. to bump lead_status), OR confirm with the user before creating the duplicate match. Never silently double-match.
Parameter interactions:
Usually created automatically by
matchLead; manual creation bypasses BD's matching logiclead_idanduser_idmust both exist (usegetLead/getUserto verify)lead_status- match lifecycle state (see Enums)match_price,lead_points,lead_rating,lead_distance- scoring fields used in ranking and billing
See also: updateLeadMatch (modify existing).
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lead_id | Yes | ||
| user_id | Yes | ||
| lead_type | No | ||
| lead_token | Yes | ||
| lead_chosen | No | ||
| lead_points | No | ||
| lead_rating | No | ||
| lead_status | Yes | Lead status (integer). NON-SEQUENTIAL enum - `3` does NOT exist; do not assume gaps are fillable: - `1` = Pending (received, awaiting action) - `2` = Matched (assigned to members) - `4` = Follow-Up (in progress) - `5` = Sold Out (no capacity) - `6` = Closed (resolved - converted or won't convert) - `7` = Bad Leads (spam/invalid) - `8` = Delete (soft-delete - hides from views) "Sold" / "won" -> `6` (Closed). Spam -> `7`. BD does NOT validate this enum - out-of-set integers are accepted and stored with undefined render behavior. Always use documented values. | |
| lead_viewed | No | ||
| match_price | Yes | ||
| lead_accepted | No | ||
| lead_distance | No | ||
| lead_response | No | ||
| lead_matched_by | Yes | ||
| lead_match_notes | No |