Pabbly Connect
Field names in Pabbly
Section titled “Field names in Pabbly”Pabbly Connect shows the API response as dotted keys rather than the flat names other marketplaces use. The table below maps them. is_deliverable has no Pabbly key; use a Filter on result.verdict instead.
| Flat name | Key in Pabbly |
|---|---|
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 |
If a step comes back pending
Section titled “If a step comes back pending”The Pabbly app has only the Verify Email action, so there is no Get Verification step to call with the id. The check still finishes on our side within 180 seconds. Open the VerifyEmail dashboard’s Single Check history to see the result for that id. Re-running the step with the same address only helps while the first check is still running: then you get the same id and no second credit is held. Once that check has finished, re-running the step starts a new check and spends another credit. Inside one workflow, a Delay step followed by a second Verify Email step on the same address has the same limits.
Connect in 3 steps
- Create an API key. In the dashboard, open Developers → API keys and create a key. Name it after Pabbly Connect so you can tell its usage apart later.
- Paste it into Pabbly Connect. When Pabbly Connect asks you to connect a VerifyEmail account, paste the key (it starts with
sk_). - Test the connection.Pabbly Connect calls Account Info (
GET /v1/me) to check the key. It costs no credits.
Set up in Pabbly Connect
- Open your workflow, add an action step and choose **VerifyEmail** as the app and **Verify Email** as the action event.
- Click **Connect** and choose **Add New Connection**. Paste your
sk_key into the **API Key** field and save. Pabbly checks it againstGET /v1/mestraight away. - Map the **Email** field from an earlier step (a form submission, a new CRM row, a sheet). It is the only input.
- Click **Save & Send Test Request**. The response panel lists
id,statusand everyresult.*key, includingresult.verdictand theresult.signals.*values. - Add a **Filter** step after it. Set it to continue only when
result.verdictequalsdeliverable(or is notundeliverable, if you want to keep risky addresses). - Map the fields you need into the next step.
result.verdict,result.quality_scoreandresult.sub_statusare the usual ones.
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.
Output fields
Verify Email returns 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.
Poll the id with GET /v1/email-verifications/{id}, which is free, or look it up in the dashboard's Single Check history. Running Verify Email again with the same address only helps while the first check is still running: then you get the same id back and no second credit is held. Once that check has finished, a repeat runs a new check and spends a credit.
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. Pabbly Connect 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 Pabbly Connect, 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
