proofwire

Verify email addresses, phone numbers and IPs in n8n, with three-state verdicts and the evidence behind them.

Package Information

Released: 1 mo ago
Downloads: 0 weekly / 0 monthly
Latest Version: 0.1.0

Documentation

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 j.smith@thecompany.com 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

MIT.

Discussion