> ## 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. # Use BounceBan in Deepline > Use BounceBan as the final email deliverability gate, especially for accept-all addresses. Includes inputs, outputs, SDK V2 examples, and Deepline cost. [Human guide: work with your agent →](https://deepline.com/docs/human/providers/bounceban/guide.md) Inspect one BounceBan action before starting provider-backed work. Your first result is a verified input and output contract. ## Provider-specific requirements Use BounceBan to verify email deliverability, particularly when an address may be accept-all or protected by a secure email gateway. * Use `bounceban_verify_single` for a single email. It may return `status: verifying`. poll `bounceban_get_single_status` with the returned id instead of submitting it again. * Use `bounceban_verify_bulk` to create a batch from known email addresses. A Play waits for the terminal result while it is running. its run log prints the BounceBan task ID and a ready-to-copy status command as soon as the task starts. Status checks back off to 30 seconds to reduce repeated polls. if the provider returns 429, Deepline waits for `Retry-After` before the next check. * If a run is canceled or times out, the remote BounceBan task may still be active. Use `deepline tools execute bounceban_get_bulk_status --input '{"id":""}'` to check it, then `bounceban_get_bulk_emails` after it finishes. Status and result reads are free. The accepted verification task may still incur Deepline credits under its normal pricing. * The account, status, and result retrieval actions are free. Do not submit an address again while its verification is still running. * Completed raw responses may wrap the verdict at `toolResponse.rawV2.data.data.result` and its score at `toolResponse.rawV2.data.data.score`. Use `email_status` for the normalized Deepline verdict. do not treat a response envelope's outer `result` key as the email verdict. * The catalog does not expose the waterfall endpoint. Its documented HTTP 408 can leave a billable task active. The shared runtime does not support settlement for that response path. ## Find an applicable action Confirm your effective workspace, then search the live catalog: ```bash theme={"languages":{"custom":["/languages/deepline-prompt.json"]}} deepline auth status --json deepline search "BounceBan" --type tools --json ``` Search returns candidates. Check the returned provider and operation rather than selecting a similar title automatically. ## Inspect the selected contract Replace `` with the identifier returned by discovery: ```bash theme={"languages":{"custom":["/languages/deepline-prompt.json"]}} deepline describe --json ``` These commands do not execute the selected provider action. Read its required inputs, supported access mode, pricing unit, outputs, and limits. A connection does not establish that every action supports BYOK. Follow the provider-specific requirements above and the live action contract. ## Prepare one reviewed input Use one authorized record that matches the inspected schema. Preserve its source identity and define the result you will accept. Open the action reference for its payload and response shape. Provider-backed execution can incur usage or external effects. For reusable logic, follow [Write Plays](https://deepline.com/docs/sdk-v2/plays.md). For direct-call recovery, use [Tool execution recovery](https://deepline.com/docs/sdk-v2/tool-execution-recovery.md). > [!TIP] > > Continue only when the workspace, provider, required fields, acceptance rule, and applicable price are understood. Keep unavailable access separate from no-result evidence. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.