Run in Enrichment Spreadsheet
Use this function as a column step in
deepline enrich.deepline enrich --input leads.csv --output leads.enriched.csv --with 'result=bounceban_verify_bulk:{"emails":"{{emails}}"}' --json
Map payload values to spreadsheet columns with
{{column_name}} placeholders.Input Schema
| Name | Type | Required | Default | Description |
|---|---|---|---|---|
payload.emails | array | Yes | (Required) A list of emails for verification. | |
payload.name | string | No | (Optional) The name for the task. If not provided, a task name will be automatically generated. | |
payload.url | string | No | (Optional) A webhook target URL specified to receive verification results events in real-time through an HTTP POST request. Each verified email will trigger a separate webhook event. In case of a failed webhook event delivery, the system will attempt to resend the event up to two additional times within a short interval. For those verifying a substantial volume of emails, it’s crucial to ensure that your webhook server is equipped to manage the incoming traffic. Services such as ngrok have been known to encounter issues when dealing with a significant number of events due to inherent limitations. We suggest exploring alternative services like TypedWebhook Tools https://typedwebhook.tools/ for a more robust solution. Please note that we are not affiliated with this service. > The webhook event will also include the event-type: bulk.email_verification_finished header so you can differentiate between different events. > Please note that the webhook event payload will be in JSON format. [ { "task_id": "68b167c5d10abc82d391f13f", "status": "success", "email": "dev@bounceban.com", "result": "deliverable", "score": 99, "is_disposable": false, "is_accept_all": false, "is_role": true, "is_free": false, "mx_records": [ "alt1.aspmx.l.google.com", "alt2.aspmx.l.google.com", "alt3.aspmx.l.google.com", "alt4.aspmx.l.google.com", "aspmx.l.google.com" ], "smtp_provider": "Google", "verify_at": "2022-11-16T07:21:24.943Z", } ] | |
payload.url_finished | string | No | (Optional) A webhook target URL specified to receive task completion events in real-time through an HTTP POST request. A webhook event will be triggered as soon as the whole task is completed. In case of a failed webhook event delivery, the system will attempt to resend the event up to two additional times within a short interval. > The webhook event will also include the event-type: bulk.task_finished header so you can differentiate between different events. > Please note that the webhook event payload will be in JSON format. { "catchall_count": 2, "credits_consumed": 2.000, "credits_remaining": 1483505.176, "deliverable_count": 0, "id": "68b167c5d10abc82d391f13f", "pushed_count": 2, "risky_count": 2, "status": "finished", "total_count": 2, "undeliverable_count": 0, "unknown_count": 0 } | |
payload.greylisting_bypass | "auto" | "speed" | "robust" | No | (Optional) Configures the retry delay for SMTP verification when an email address is temporarily rejected due to greylisting. Learn more about greylisting here: https://en.wikipedia.org/wiki/Greylisting_(email). Default is auto. > auto: The default and recommended setting. This option automatically adjusts the retry delay to balance verification speed with the success rate. We typically use a shorter delay for smaller lists and a longer one for larger lists to optimize performance. > speed: Sets the retry delay to approximately one minute. Recommended for small lists (e.g. fewer than 1000 emails) and tasks that are time sensitive. This prioritizes faster results, but it may lead to more emails being flagged as risky. Verification can occasionally take longer if greylisting occurs at multiple stages of the SMTP process. > robust: Sets the retry delay to approximately five minutes. Recommended for larger lists (e.g. more than 1000 emails) and tasks that are not time sensitive. This prioritizes accuracy and results in fewer risky flags for greylisted emails. As with the speed option, the total verification time can still be longer if the server greylists multiple SMTP commands. | |
payload.mode | "regular" | "deepverify" | No | (Optional) Verification mode to apply for all the emails in the bulk verification task. Default is regular. > regular: The default option for email verification. It does not assume that the domain of the email owner’s current company website matches the domain of the email being verified. > deepverify: DeepVerify operates on the assumption that the domain of the email owner’s current company website matches the domain of the email being verified. This assumption can improve the success rate of verifying accept-all emails. However, it is crucial to obtain the domain for the email owner’s current company website from a reliable source, such as the email owner’s LinkedIn profile or another trustworthy sales prospecting database. Learn more: https://support.bounceban.com/article/what-is-deepverify | |
payload.disable_catchall_verify | "0" | "1" | No | (Optional) Defaults to 0. When set to 1, BounceBan performs only basic SMTP verification. This may leave catch-all emails or those protected by ESGs (Email Security Gateways) unverified. For these addresses, the API will return result: 'unknown', score: -1, and the credit cost is 0. |
Allowed values
| Field | Allowed values |
|---|---|
payload.greylisting_bypass | auto, speed, robust |
payload.mode | regular, deepverify |
payload.disable_catchall_verify | 0, 1 |
Output Schema
| Name | Type | Required | Default | Description |
|---|---|---|---|---|
result.data | object | Yes | Provider response payload. | |
result.meta | object | No | Additional response metadata (status, paging). |
Advanced: Direct CLI
Use direct execution for single payload debugging.
deepline tools execute bounceban_verify_bulk --payload '{
"emails": "array"
}' --json
CLI flags
| Flag | Description |
|---|---|
--json | Print machine-readable output. |
--wait | Wait for terminal provider status when supported. |
--debug | Enable wait mode with additional status/log output. |
--wait-timeout SECONDS | Max seconds to wait in wait mode. |
--poll-interval SECONDS | Polling interval in seconds during wait mode. |
--timeout SECONDS | Request timeout in seconds. |
--connect-timeout SECONDS | Connection timeout in seconds. |
Provider API Context
Cost
- Pricing model:
per_result(per result). - Estimated Deepline credits:
0.06per pricing unit. - Billing mode:
post_deduct.