Integrations

Validation inside the tool where the workflow already lives — with the one thing every other validator node in those catalogues cannot express.

The IF node is the wrong shape

Every validator in every automation catalogue answers valid or invalid, so the node people reach for next is an IF. Two branches, one decision, done.

That shape cannot express a catch-all domain, and a large minority of business mail servers are one: they accept every address you ask about, whether or not the mailbox exists. Nothing observable distinguishes a real colleague from a fictional one. Validators that must answer valid-or-invalid answer valid, and bill you. Your workflow sends. 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 them to retype it
                └── unknown  ──▶ hold for review

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

n8n

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

n8n-nodes-proofwire

Resource	Operation	Cost
Email	Verify	1 credit	Syntax, domain records, live mailbox probe
Email	Find	15 credits	Name and domain to 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

Every call carries an idempotency key derived from the execution and the item, so an n8n retry replays the stored answer instead of spending again. The credential test calls the usage endpoint, so pressing Test costs nothing — a credential test that spends a credit is one people learn not to press.

Zapier and Make

Both are being built, and neither is listed yet. They are not ours to publish on our own schedule: an app appears in those directories after the platform reviews it, which takes weeks and is not something we can promise a date for.

Until then both platforms can call the API directly through their HTTP step, and the docs cover it. If you are waiting on one of them specifically, say so at support@proofwire.app — it decides the order.

Everywhere else

The MCP server puts the same checks in front of an AI assistant. The TypeScript and Python clients refuse, at the type level, to let three verdicts become two. The API is plain HTTP and JSON underneath all of it.

You need a key from the keys page. Signup gives you 100 credits, no card. A pk_test_ key answers from fixed sandbox fixtures and is never billed, which is the one to build a workflow with before letting it run for real.