Skip to main content
Human guide: work with your agent → 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":"<task-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:
Search returns candidates. Check the returned provider and operation rather than selecting a similar title automatically.

​
Inspect the selected contract

Replace <returned-tool-id> with the identifier returned by discovery:
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. For direct-call recovery, use Tool execution recovery.
Continue only when the workspace, provider, required fields, acceptance rule, and applicable price are understood. Keep unavailable access separate from no-result evidence.