Make
Module names in Make
Section titled “Module names in Make”Make names modules with a verb and an object, so the operations appear under these names:
| Operation | Make module |
|---|---|
| Verify Email | Verify an email address |
| Get Verification | Get a verification |
| Account Info | Get account info |
Field names in Make
Section titled “Field names in Make”Make modules return the API response unchanged, so the fields are nested rather than flat, and there is no is_deliverable. Filter on result.verdict equal to deliverable instead. A pending result has no result at all, only id, status, poll_after_ms and next_retry_at.
| Flat name | Key in Make |
|---|---|
id, status |
id, status |
email, verdict, sub_status, quality_score, confidence, provider, primary_mx, verified_at |
result.email, result.verdict, … result.verified_at |
signal_syntax … signal_greylisting |
result.signals.syntax … result.signals.greylisting |
is_deliverable |
none; filter on result.verdict |
The app also has Make an API call. It sends any request to https://api.tryverifyemail.com with your key already attached, for endpoints the modules don’t cover.
Rate limits in Make
Section titled “Rate limits in Make”When the API answers 429, the module fails with a rate-limit error that names your plan’s rate. Make then suspends the scenario and resumes it on its own, about 20 minutes later by default. It does not retry inside the same run. If you would rather skip the address and carry on, add a Break or Ignore error handler to the module.
Connect in 3 steps
- Create an API key. In the dashboard, open Developers → API keys and create a key. Name it after Make so you can tell its usage apart later.
- Paste it into Make. When Make asks you to connect a VerifyEmail account, paste the key (it starts with
sk_). - Test the connection.Make runs Account Info to check the key. You should see your account email and credit balance. It costs no credits.
Set up in Make
- In your scenario, click **+**, search for **VerifyEmail** and choose **Verify an email address**.
- Next to **Connection**, click **Create a connection**. Paste your
sk_key into **API key** and click **Save**. Make checks the key againstGET /v1/meand names the connection after your account email. - Map **Email address** from an earlier module (a form response, a new CRM record, a sheet row). It is the only input.
- Click **Run once**. The output bundle is the API response as it is:
Verification ID,Statusand aResultcollection holdingVerdict,Quality scoreand aSignalscollection. See the field names below. - Add a filter on the route after it, for example
Result: Verdictequal todeliverable. - To finish a check that came back
pending, add **Tools → Sleep** for about 60 seconds, then **VerifyEmail → Get a verification** with theVerification IDfrom the first module.
Operations
Verify Email
Runs a fresh live check of one address and returns the flat result below. If the mail server is slow, the step returns status: pending instead of a verdict.
POST /v1/email-verifications
- Email (required): The address to check. A malformed address is not an error: it comes back
undeliverable/invalid_syntax.
Get Verification
Fetches a check by id. Use it to finish a Verify Email step that came back pending. Returns the same flat fields.
GET /v1/email-verifications/{id}
- Verification ID (required): The
idoutput of a Verify Email step.
Account Info
Returns the account email, plan, the credits it can spend right now, and the key's label and mode. Costs nothing, so it doubles as the connection test.
GET /v1/me
No inputs.
Output fields
Verify Email and Get Verification return one flat object with the same fields, in the same order, on every marketplace. While a check is pending, every field except id and status isnull, including is_deliverable.
| Field | Type | Meaning |
|---|---|---|
id | string | The verification id. Pass it to Get Verification. |
status | string | completed, or pending while the check is still running. |
email | string | null | The address exactly as submitted. |
normalized_email | string | null | The canonical form the verdict was computed against: trimmed, domain lower-cased. |
verdict | string | null | deliverable, undeliverable, risky or unknown. |
sub_status | string | null | A refinement such as mailbox_exists, catch_all, invalid_syntax or timeout. New values may appear. |
quality_score | integer | null | 0 to 100. Higher is safer to send to. |
confidence | integer | null | 0 to 100. How sure the API is of the verdict itself. |
provider | string | null | The mailbox host, such as google, microsoft or self_hosted. null when it could not be determined. |
primary_mx | string | null | The domain's highest-priority mail server hostname. |
signal_syntax | string | null | The address is well-formed. pass, fail, warn, unknown or skipped. |
signal_domain | string | null | The domain exists in DNS. pass, fail, warn, unknown or skipped. |
signal_mx | string | null | The domain publishes mail servers. pass, fail, warn, unknown or skipped. |
signal_smtp | string | null | The mail server accepts the mailbox. pass, fail, warn, unknown or skipped. |
signal_catch_all | string | null | Whether the domain accepts every address. pass, fail, warn, unknown or skipped. |
signal_role_account | string | null | Whether the local part is a shared role such as info@. pass, fail, warn, unknown or skipped. |
signal_disposable | string | null | Whether the domain is a throwaway provider. pass, fail, warn, unknown or skipped. |
signal_dnsbl | string | null | Whether the domain or its mail servers are on DNS blocklists. pass, fail, warn, unknown or skipped. |
signal_toxic | string | null | Whether the address is a known spam trap. pass, fail, warn, unknown or skipped. |
signal_greylisting | string | null | Whether the server greylisted the check and a retry cleared it. pass, fail, warn, unknown or skipped. |
verified_at | string | null | When the verdict was produced, ISO 8601 UTC. |
is_deliverable | boolean | null | true only when verdict is deliverable. null while pending. |
To branch, filter on verdict. is_deliverable is a shortcut forverdict = deliverable. Full definitions are in the result object.
When the result is pending
Some mail servers take longer to answer than a marketplace step is allowed to wait. When that happens the step still succeeds, with status: pending and an id, instead of guessing a verdict. The check keeps running on our side.
Add a Get Verification step (after a short delay, if Make offers one) and pass it the id. It returns the finished result, or pending again if the server still hasn't answered.
Every check finishes within 180 seconds. If the recipient's mail server never answers, the result isverdict: unknown, sub_status: timeout, and that check is not charged.
Rate limits and credits
- 429 Too Many Requests. Your plan allows a set number of requests per second. The integration waits the
Retry-Aftertime and retries once. If it is still limited, the step fails with a message naming your plan's rate. Space out the runs or move to a plan with a higher rate. - 402 Payment Required. Either the account has no credits left (
insufficient_credits; nothing was started or charged) or it is frozen (account_frozen). The step fails with a link to Billing. Top up and re-run. - 401 Unauthorized. The key is missing, revoked, or the request came from an IP the key doesn't trust (see below).
API key notes
- Trusted IPs. A key can be limited to a list of trusted IP addresses or ranges. Make calls the API from its own servers, not from your computer, so a key with an allowlist that doesn't cover those servers answers
401. Leave the allowlist empty on the key you give Make, or use a separate key for it. - Test keys. "Test" is only a label on the key. A test key runs real checks and spends real credits, the same as a live key.
Screenshots
