BounceBan: Verify Bulk

Create a bulk email-verification task.

Tool ID: bounceban_verify_bulk

Run this action

Use the TypeScript SDK for a single call. Put ctx.tools.execute(...) inside a Play when the call should be durable, scheduled, or run across a CSV.

import { Deepline } from 'deepline';

const deepline = await Deepline.connect();
const result = await deepline.tools.execute(
  'bounceban_verify_bulk',
  {
    "emails": [
      "jane.doe@example.com"
    ]
  },
);

console.log(result.toolResponse.raw);

CLI

deepline tools execute bounceban_verify_bulk --input '{
  "emails": [
    "jane.doe@example.com"
  ]
}' --json

Example response

The SDK exposes this shape at result.toolResponse.raw. Values below are representative.

{
  "data": {
    "id": "id_123"
  }
}

Use deepline tools get bounceban_verify_bulk --json for the latest machine-readable contract.

Input reference

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.

Name	Type	Required	Default	Details
`payload.emails`	`array`	Yes	—	(Required) A list of emails for verification. Minimum items: 1.
`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 See the live schema for the complete constraint.
`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 See the live schema for the complete constraint.
`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 See the live schema for the complete constraint.
`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 See the live schema for the complete constraint.
`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: `0`, `1`.

Output reference

Standard tool result payload.

Name	Type	Required	Default	Details
`result.data`	`object`	Yes	—	Provider response payload.
`result.data.id`	`string`	No	—	Unique ID for this bulk verification task. You can use this ID to get the verification result.
`result.meta`	`object`	No	—	Additional response metadata (status, paging).

Deepline cost

Pricing model: per_result (per result).
Estimated Deepline credits: 0.06 per pricing unit.

Get started

Build and automate

Common workflows

Data and integrations

Reference

BounceBan: Verify Bulk

Run this action

CLI

Example response

Input reference

Output reference

Deepline cost

​Run this action

​CLI

​Example response

​Input reference

​Output reference

​Deepline cost

​Related documentation

Run this action

CLI

Example response

Input reference

Output reference

Deepline cost

Related documentation