MailWizz + VerifyAnyEmail
API recipeKeep MailWizz lists clean by verifying subscribers through the API — either as they’re added (via a webhook/endpoint) or in a scheduled batch that flags undeliverable subscribers. All integrations call POST https://api.verifyany.email/v1/verify with an Authorization: Bearer <API_KEY> header and a JSON body of {"email":"..."}. The response includes result.status (deliverable / undeliverable / risky / unknown) and result.score.
Setup
- 1Export or read subscribers
Use MailWizz’s own API to pull subscribers for a list, or hook into subscriber creation.
- 2Verify each address
Call POST /v1/verify with X-VAE-Source: mailwizz for each email (or use the batch endpoint for large lists).
- 3Act on the result
Unsubscribe or mark as “unconfirmed” any subscriber whose status is undeliverable, so they’re excluded from future campaigns.
$ch = curl_init('https://api.verifyany.email/v1/verify');
curl_setopt_array($ch, [
CURLOPT_POST => true,
CURLOPT_RETURNTRANSFER => true,
CURLOPT_HTTPHEADER => [
'Authorization: Bearer YOUR_API_KEY',
'Content-Type: application/json',
'X-VAE-Source: mailwizz',
],
CURLOPT_POSTFIELDS => json_encode(['email' => $email]),
]);
$data = json_decode(curl_exec($ch), true);
$status = $data['result']['status']; // deliverable | undeliverable | risky | unknownHandling the result
Every verification returns a result object with a status, a 0–100 score and a “did you mean” suggestion for typos. Branch on the status:
| status | Meaning | Recommended action |
|---|---|---|
| deliverable | Mailbox exists and accepts mail | Accept |
| undeliverable | Invalid syntax, no MX, or rejected mailbox | Block / reject |
| risky | Accepts but low quality (catch-all, role, disposable) | Allow with caution, or challenge |
| unknown | Couldn’t determine (greylist, timeout, blocked port) | Allow (fail-open) or retry later |
For sign-up and checkout forms, the safe default is to block only undeliverable so you never turn away a real customer, and to surface the suggestion (“did you mean gmail.com?”) inline to recover typos.
Security & reliability
- Keep your API key server-side. Never expose it in client-side JavaScript. In MailWizz, store it in the integration’s credential/secret store, not in a shared script.
- Fail open. If the API errors or times out, let the address through rather than blocking a real user over a transient issue.
- Retry transient errors. Back off and retry on
429(rate limit) and5xx; don’t retry4xxvalidation errors. - Cache per address. One credit is spent per unique verification — cache results (e.g. 12–24h) so re-submits don’t re-charge.
- Tag the source. This recipe sends
X-VAE-Source: mailwizzso your dashboard shows where verifications come from.
Troubleshooting
| Response | Cause & fix |
|---|---|
| 401 | Missing or wrong API key — check the Authorization header is Bearer YOUR_API_KEY. |
| 402 | Out of credits — top up in the dashboard. (The plugin fails open in this case.) |
| 429 | Rate limited — slow down or upgrade your plan; back off and retry. |
| No result written | Confirm you’re reading result.status, and that the request body is { "email": "…" } as JSON. |
This is an API recipe, not a one-click app — you wire it up once with the steps above. See the full API reference for every field and error code.