Skip to main content
The identity resolver preserves a receipt when contact evidence conflicts or cannot identify a lead. These are submissions, not a count of distinct people. Resolution preserves the original refusal and records a separate actor, reason, decision, and resulting write receipt.

​
Inspect and preview

List the queue with erdo leads candidates <dataset> --json. The --traffic filter accepts real, test, or all. test contains only traffic independently verified by the platform as a test. A sender’s own is_test marker remains metadata and cannot remove a refusal from the default real queue or its attention item. The filter applies before the result limit. All dates and campaigns are covered. Create a decision file:
Run erdo leads resolve-capture <dataset> <receipt> --input decision.json. Read the saved capture.evidence.normalized_capture beside target_row. Historical evidence is read from the original persisted execution, never reconstructed with today’s transform or supplied by the caller. For older conversation receipts identified by a provider source key, the platform checks the complete retained execution history for that pipeline and organization. A preview requires exactly one execution whose source key and original payload digest match the receipt, with an intact normalized submission. Missing, truncated, duplicate or unprovable evidence blocks the preview. Histories of 10,001 or more executions also require separate investigation. Current submissions keep their execution link directly; this historical check never applies a decision or replays a conversation. To dismiss without applying the submission, use action: "dismiss", omit target_lead_id, and explain the decision in reason.

​
Confirm the exact decision

Add the preview’s opaque snapshot as expected_snapshot and a unique, stable operation_key to the same decision file, then run the command with --apply. A changed target or receipt requires another preview. Retry an uncertain response with the same key and exact decision; a conflicting replay is refused. Applying writes the saved submission into an existing candidate lead using the normal identity, attribution, consent, qualification, and contract guards. It does not merge identities, create another acquisition conversion, repeat paid lookups, or trigger another arrival notification. Dismissal writes only the audit decision. The unresolved queue excludes disposed receipts. Both operations require organization operator access and dataset edit permission. The evidence-bearing candidate queue also requires dataset edit permission; ordinary lead reads expose refusal metadata without the submission or disposition. Scoped end-user credentials cannot adjudicate another lead. Applying preserves the saved record_form_answers decision. A non-form producer or historical submission without that decision cannot establish lead-authored form answers, even though its saved values can update the candidate row.

​
REST and MCP

POST /v1/datasets/{datasetSlug}/lead-captures/{captureID}/resolve accepts the decision fields above. apply defaults to false; applying requires the preview snapshot and operation key. GET /v1/datasets/{datasetSlug}/lead-candidates accepts limit and traffic. The erdo_preview_lead_capture_resolution MCP tool inspects and previews the same evidence. Applying contradictory contact evidence remains an explicit operator action through REST or CLI, as it is for lead merges.

​
Future contact corrections

An accepted browser capture returns a short-lived captureContinuation token. The landing SDK sends it with a later submission to the same pipeline. The server verifies its organization, dataset, pipeline, lead, and expiry before allowing the existing correction rule. A matching phone, caller-supplied lead ID, or unsigned session identifier alone does not prove the same visitor. Missing or invalid proof uses ordinary identity resolution and preserves any refusal for review.