> ## Documentation Index > Fetch the complete documentation index at: https://docs.erdo.ai/llms.txt > Use this file to discover all available pages before exploring further. # Resolve refused submissions > Review saved submission evidence and record a decision without merging people or replaying automations. 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 --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: ```json theme={null} { "action": "apply_to_lead", "target_lead_id": "candidate-canonical-lead-uuid", "reason": "Compared the submitted details with the candidate's contact evidence." } ``` Run `erdo leads resolve-capture --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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.