n8n-nodes-proofwire

Verify email addresses, phone numbers and IPs inside an n8n workflow — with a verdict that is allowed to say it does not know.

Proofwire is a validation API. This is its community node.

Install

Self-hosted n8n: Settings → Community Nodes → Install, then enter

n8n-nodes-proofwire

Then add a Proofwire credential with a key from proofwire.app/keys. Signup gives you 100 credits, no card. A pk_test_ key answers from fixed sandbox fixtures and is never billed — build the workflow with that one.

The part that changes how you wire it

Most validators answer valid or invalid, so the natural n8n shape is an IF node. That shape is wrong, and it is wrong in a way that costs you deliverability.

A large minority of business mail servers are catch-all: they accept every address you ask about, whether or not the mailbox exists. Nothing can be established about [email protected] on such a domain. Validators that must answer valid-or-invalid answer valid, and bill you. Your workflow then sends, and you find out at the bounce.

Proofwire answers in three states, and unknown is one of them. It arrives with the reason, and it is never billed.

So the node feeds a Switch, not an IF:

Proofwire ──▶ Switch on {{ $json.verdict }}
                ├── valid    ──▶ send
                ├── invalid  ──▶ drop, or ask the person to retype it
                └── unknown  ──▶ hold for review, or send to the addresses
                                 you already have a reply from

Three outputs, because there are three answers. The node never throws on unknown — an inconclusive verdict is the product working, and routing it into an error branch alongside timeouts and bad credentials loses exactly the information you installed this for.

The control probe

Before an acceptance is believed, the server is asked about an address that cannot exist. If it accepts that too, its acceptance of the real address carries no information, and the verdict says so rather than rounding up:

{
  "verdict": "unknown",
  "confidence": 0.52,
  "risk": 10,
  "attributes": { "catchAll": true, "domain": "thecompany.com" },
  "evidence": [
    { "source": "mx",   "signal": "mx_records_present", "detail": "1 MX record published.", "weight": 1.9 },
    { "source": "smtp", "signal": "catch_all_detected", "detail": "Control probe: the server also accepted an address that cannot exist, so its acceptance carries no information.", "weight": -1.4 }
  ],
  "billing": { "credits_charged": 0, "reason": "Inconclusive verdict - not billed.", "balance_after": 100 }
}

evidence[].weight is in log-odds: positive argues for validity, negative against, and zero is informational. It is the audit trail for the verdict, which is what you show a customer who asks why their address was rejected.

Operations

| Resource | Operation | Cost | | |---|---|---|---| | Email | Verify | 1 credit | Syntax, domain records, live mailbox probe | | Email | Find | 15 credits | Name + domain → an address that was checked, not guessed | | Phone | Verify | 1 credit | Numbering plan, line type, live carrier query | | IP Address | Verify | 1 credit | Operator, datacentre, Tor exit, from published ranges | | Company | Profile | 5 credits | Mail provider, SPF/DMARC/DKIM posture, domain age, registrar, EU VAT registry |

Inconclusive verdicts are free. Repeats inside the cache window are free. A landline is never billed for a mobile-network query it could not have been in. Every response says what it charged and why.

Email → Find

Email finders are the worst inventors of false confidence in the industry: they return "95% confidence" on a pattern they guessed and never tested. This one probes the candidates in order and returns an address only when a mail server confirmed that specific mailbox. When the domain accepts everything, it says so — outcome: "accepts_everything" — and charges nothing, because a guess is not a product.

Common shapes

Clean a list before a campaign. Read the sheet → Proofwire (Email → Verify) → Switch. valid to the send branch, invalid back to the sheet marked, and unknown to a second sheet a human looks at. Set the node's Always Output Data off and Retry On Fail on; each call carries an idempotency key, so a retry replays the answer instead of spending again.

Score a signup at the door. Webhook → Proofwire (Email → Verify) → IF on {{ $json.risk > 70 }} → hold for review. Disposable domains, brand-new domains and no-mail-server domains are already in that score.

Fraud check on an order. Proofwire (IP Address → Verify) → IF on {{ $json.attributes.connectionType === 'datacenter' }}. A residential customer ordering from a datacentre IP is worth a second look; a business customer on a VPN is not.

Enrich an inbound lead. Proofwire (Company → Profile) on the email's domain gives you the mail provider, the DMARC posture, the domain age and — with a VAT number — the registered legal name and address straight from the member state's registry.

Notes

• Batching. The node runs once per input item and pairs each output back to its input, so $json downstream lines up with the row you started from.
• Idempotency. Every call sends Idempotency-Key: n8n-<executionId>-<item>. An n8n retry, or a re-run of a failed execution, replays the stored answer rather than billing twice.
• Continue On Fail puts { "error": "..." } on the item and carries on. Note again that unknown never lands there.
• Credential test calls /v1/usage, so pressing Test costs nothing.
• Your key stays on your instance. The node calls the API directly from wherever n8n runs.

Links

• Documentation
• Published accuracy benchmark — dataset downloadable, so you can rerun it yourself
• Status · Changelog
• Source and issues

MIT.