> ## Documentation Index
> Fetch the complete documentation index at: https://deepline.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Bounceban Verify Bulk: Inputs, Cost & CLI Example
> Create a bulk email-verification task. Includes inputs, outputs, pricing notes, Deepline CLI examples, and GTM automation guidance.
## Run in Enrichment Spreadsheet
Use this function as a column step in `deepline enrich`.
```bash theme={null}
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/](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)](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](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` |
Show raw input schema
### Input JSON Schema
````json theme={null}
{
"type": "object",
"description": "The API allows you to submit a list of emails for verification in batches. While there is no strict limit on the number of emails you can submit per task, we recommend keeping it under 500,000 emails per task for optimal performance. If you need to submit a larger list, please contact our support team. Additionally, there is a soft limit on the total number of concurrent emails in the verifying state (excluding pending emails from the same task) across all tasks from the same account. This limit is dynamic and depends on the global system load to ensure optimal performance for all users. If you have specific requirements, our support team is available to assist you.",
"properties": {
"emails": {
"type": "array",
"description": "(Required) A list of emails for verification.",
"minItems": 1,
"items": {
"type": "string"
}
},
"name": {
"type": "string",
"description": "(Optional) The name for the task. If not provided, a task name will be automatically generated."
},
"url": {
"type": "string",
"description": "(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/](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\", } ] ```"
},
"url_finished": {
"type": "string",
"description": "(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 } ```"
},
"greylisting_bypass": {
"type": "string",
"description": "(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)](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.",
"enum": [
"auto",
"speed",
"robust"
]
},
"mode": {
"type": "string",
"description": "(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](https://support.bounceban.com/article/what-is-deepverify)",
"enum": [
"regular",
"deepverify"
]
},
"disable_catchall_verify": {
"type": "string",
"description": "(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.",
"enum": [
"0",
"1"
]
}
},
"required": [
"emails"
],
"additionalProperties": false
}
````
## Output Schema
| Name | Type | Required | Default | Description |
| ------------- | -------- | -------- | ------- | ---------------------------------------------- |
| `result.data` | `object` | Yes | | Provider response payload. |
| `result.meta` | `object` | No | | Additional response metadata (status, paging). |
Show raw output schema
### Output JSON Schema
```json theme={null}
{
"type": "object",
"description": "Standard tool result payload.",
"properties": {
"data": {
"type": "object",
"description": "Provider response payload.",
"properties": {
"id": {
"type": "string",
"description": "Unique ID for this bulk verification task. You can use this ID to get the verification result."
}
},
"additionalProperties": false
},
"meta": {
"type": "object",
"description": "Additional response metadata (status, paging).",
"additionalProperties": true
}
},
"required": [
"data"
],
"additionalProperties": false
}
```
## Advanced: Direct CLI
Use direct execution for single payload debugging.
```bash theme={null}
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
Show provider reference (optional)
```md theme={null}
Sources reviewed 2026-07-26:
- https://bounceban.com/public/doc/api.yaml
- https://bounceban.com/public/doc/llms.txt
## Auth
BounceBan expects the managed API key in the `Authorization` header, without a Bearer prefix.
## Pricing
- Single verification and each successfully verified email in a bulk task consume one BounceBan verification credit.
- The normal single verification response and completed bulk-status response expose `credits_consumed`; this is the preferred settlement input.
- A basic single verification with `disable_catchall_verify=1` can return `unknown` with zero verification cost.
- Single and bulk result polling, result retrieval, exports, task deletion, and account lookup do not consume verification credits.
- The configured managed-account provider exchange rate is $0.004 per BounceBan credit, as directed for this integration.
## Endpoint notes
The standard single verification call can return `status: verifying`; poll the free single-status endpoint with its id rather than submitting the email again. The waterfall endpoint can return HTTP 408 while retaining the verification task; BounceBan documents retries for the same email within 30 minutes as free.
The bulk file upload is documented as `multipart/form-data`. It remains registered but disabled until the shared V2 runtime gains multipart transport, so it cannot silently send malformed JSON. The waterfall endpoint is also disabled: its HTTP 408 can retain a billable task, which requires a non-2xx async settlement path before it can be exposed safely.
## Response evidence
`raw-upstream-examples/single-success.json` preserves the provider's documented single-verification response, including `credits_consumed`. `raw-upstream-examples/bulk-status-finished.json` preserves the completed bulk-status response and its task-level `credits_consumed`. Normalized Deepline samples are stored separately under `sample-outputs/`.
```
## Cost
* Pricing model: `per_result` (per result).
* Estimated Deepline credits: `0.06` per pricing unit.
* Billing mode: `post_deduct`.