Batches & Automation

Running Campaigns

Start batches, control concurrent tabs, pause or stop mid-run, and handle bot detection or captchas.

Once your agent is set up and your URLs are imported, starting a batch takes one click. Here is exactly what happens from click to first form submission.

1. Prerequisites

Before you can start a batch, three things must be true:

  • You are signed into the extension. Check the side panel; you should see your queue, not a sign-in screen.
  • URLs are in the queue. From an import, a paste, or a saved list. If the queue is empty, add URLs first.
  • You have website credits. Free tier has 30; paid plans have their included quota plus any purchased extras. If your balance is zero, buy credits before starting.

2. Pick The Active Agent

  • Open the extension side panel.
  • The agent switcher is at the top.
  • Click it and pick the agent for this batch.

The agent you pick decides the sender identity, pitch, subject, and whether AI Personalization applies to this batch. All URLs in the batch use the same agent.

3. Click Start

  • The Start Batch button sits at the top of the Queue view.
  • Click it.
  • A confirmation dialog appears with a summary: number of URLs, active agent, AI cost estimate (if applicable), estimated time to finish.
  • Click Start.

4. What Happens First

The moment you click Start, ContactID:

  • Reserves your credits. The estimated cost is provisionally reserved so you cannot accidentally start a second batch that would overspend.
  • Opens the first tabs. Up to your Max Concurrent Tabs setting (default 3). Each tab opens the target URL in the background.
  • Runs the content script on each page. The script detects the contact form, fills it, and submits.
  • Marks the URL as COMPLETED, FAILED, or SKIPPED based on the outcome.
  • Advances to the next URL. As each tab finishes, a new one opens to keep the concurrency window full.

5. Watching Progress

The Queue view updates in real time:

  • Progress bar at the top shows overall completion.
  • Each URL row shows its current status (QUEUED, IN_PROGRESS, COMPLETED, FAILED).
  • Live counters show sent, failed, remaining, and running credit spend.

You can leave the tab and work on other things; the batch runs in the background as long as Chrome stays open.

6. Finishing The Batch

When the last URL is processed:

  • The status flips to COMPLETED (or PARTIALLY_COMPLETED if any errored).
  • A completion toast appears in the extension.
  • A summary email is sent to your account email address.
  • Full results are available in Activity and the Import Job’s detail view.

7. Starting A Second Batch On The Same Device

You can start a new batch as soon as the previous one finishes. Import new URLs (or reuse a saved list), pick the agent, click Start. The extension does not carry any state from the previous batch.

Every URL in the extension side panel shows a status label. Knowing what each means lets you read a running batch at a glance and decide when to intervene.

1. The Six Statuses

Every URL goes through some subset of these:

  • QUEUED. In the list but not yet started. Waiting for a tab slot to open.
  • IN_PROGRESS. The URL is currently open in a tab; the content script is running.
  • COMPLETED. Form was found, filled, and submitted successfully. A credit was consumed.
  • FAILED. Attempted but did not complete. Reason shown on click; no credit consumed.
  • SKIPPED. Duplicate or filtered before send. No credit consumed.
  • CANCELLED. You cancelled the batch before this URL was attempted.

2. QUEUED — Waiting To Start

QUEUED URLs are in your list but not yet being processed. Two reasons they wait:

  • The concurrent tab window is full. If you set Max Concurrent Tabs to 3 and three tabs are already IN_PROGRESS, the next URL waits until one finishes.
  • A rate limit is throttling. ContactID enforces 60 submissions per minute across your account; QUEUED URLs pause briefly to stay under it.

You can start a batch, close the side panel, and come back later; QUEUED URLs will be picked up automatically as slots open.

3. IN_PROGRESS — Currently Being Filled

IN_PROGRESS means Chrome has opened the URL in a background tab and the ContactID content script is running on the page. The script is:

  1. Detecting the contact form’s field structure.
  2. Matching each field to the corresponding agent data (name, email, message).
  3. (If AI Personalization is on) Fetching AI-personalized text.
  4. Filling every detected field.
  5. Clicking Submit.
  6. Waiting for confirmation.

Typical IN_PROGRESS duration is 8 to 20 seconds. Longer than 60 seconds usually means the target site is slow to load; the tab times out at 90 seconds and is marked FAILED.

4. COMPLETED — Form Submitted Successfully

COMPLETED means all of these happened:

  • Form was found on the page.
  • All required fields were filled.
  • Submit button was clicked.
  • The page returned a success signal (thank-you page, success message, redirect).

A COMPLETED status consumes one website credit. Cost is deducted from your balance at completion time, not at start-of-batch.

5. FAILED — Something Did Not Work

FAILED covers several possible reasons. Click the URL row to see the specific reason:

  • Form not detected. No contact form was found on the page. Common on landing pages that link out to a separate contact page.
  • Bot detection blocked submission. Cloudflare, hCaptcha, or reCAPTCHA blocked the submit. See the article on bot detection.
  • Required field could not be filled. Some forms have fields the extension does not know how to fill (specific dropdown options, date pickers, file uploads).
  • Network timeout. The page took too long to load or the submission never got a response.
  • Site rejected the submission. Server returned an error after Submit was clicked.

FAILED does not consume a credit. The URL can be retried; see the article on retry logic.

6. SKIPPED — Not Sent By Design

SKIPPED covers:

  • Duplicate URL already in your queue from a previous import.
  • Recently contacted URL within the cooldown period (default 7 days).
  • Blocklisted domain that ContactID does not send to.

Skipped URLs are shown in the Queue view but do not consume credits or affect the batch outcome.

7. Filtering The Queue View

The Queue view has status filter chips at the top:

  • Show only IN_PROGRESS to watch what is happening right now.
  • Show only FAILED to see what needs attention.
  • Show only COMPLETED to review what has been sent.

Combine filters and search to find specific URLs quickly during large batches.

The Max Concurrent Tabs setting decides how many websites the extension processes simultaneously. Tuning it matters for speed, memory use, and success rate. Here is how to pick the right number.

1. Where To Change It

  • Open the extension side panel.
  • Click the Settings icon (top right).
  • The Max Concurrent Tabs slider goes from 1 to 8.
  • Change and save; new setting takes effect on the next tab opened.

2. What Each Level Does

  • 1 tab. One URL at a time. Slowest but easiest on memory. Useful on older laptops or when you want to browse normally alongside.
  • 2 to 3 tabs. Balanced. Roughly 2x to 3x throughput of single-tab mode with minimal memory cost.
  • 3 to 5 tabs. The sweet spot for most users on modern computers.
  • 5 to 8 tabs. Fast but memory-heavy. Only recommended on desktops with 16 GB+ RAM.
  • Above 8 tabs. Not supported. Chrome starts throttling background tabs at higher concurrency, which causes false failures.

3. How Concurrency Affects Speed

Rough throughput at each level:

  • 1 tab: ~4 URLs per minute.
  • 3 tabs: ~10 URLs per minute.
  • 5 tabs: ~15 URLs per minute.
  • 8 tabs: ~20 URLs per minute.

Actual throughput depends on how fast target sites load and how much the AI takes on each request.

4. Rate Limit Ceiling

Regardless of your concurrency setting, ContactID enforces a maximum of 60 form submissions per minute across your account. At 8 concurrent tabs on fast sites, you can hit this ceiling; if so, the extension automatically holds new tabs open briefly to stay under.

You do not need to worry about this; it self-regulates.

5. Memory Impact

Each tab uses about 100 to 300 MB of RAM. At 5 concurrent tabs, ContactID uses 500 MB to 1.5 GB during a batch. Combined with the rest of Chrome, this can make a laptop slow.

If you see Chrome getting laggy, drop concurrency to 2 or 3.

6. When To Reduce Concurrency

Lower it when:

  • Your laptop only has 8 GB RAM.
  • You want to do other work in Chrome during the batch.
  • You are on unstable internet where multiple concurrent requests cause timeouts.
  • Success rate is unusually low; lower concurrency sometimes helps flaky sites.

7. When To Raise Concurrency

Higher only if:

  • You have 16 GB+ RAM.
  • Your internet is fast and stable.
  • You will not be using Chrome for anything else during the batch.

The gain from 5 to 8 is small (roughly 30% more throughput), so most users stick with 3 to 5.

8. Concurrent Tabs Per Account, Not Per Device

Each device has its own concurrency setting. If you run batches on two devices simultaneously with 5 tabs each, that is 10 concurrent tabs from your account across the two devices. The 60-per-minute rate limit still applies to the total.

Pausing lets you take a break without losing your queue. Stopping (cancelling) ends the batch entirely. Here is how to do each and when to pick which.

1. Pause From The Extension

The fastest way:

  • Open the extension side panel.
  • Click Pause in the top right of the Queue view.
  • All new tabs stop opening. Tabs currently IN_PROGRESS finish their current form.
  • The batch enters PAUSED state.

2. Resume From Pause

  • With the batch paused, the button changes to Resume.
  • Click it.
  • The concurrency window fills again; batch continues.

You can pause and resume as often as you want. There is no cost or penalty.

3. Cancel A Batch

To end the batch entirely and clear the queue:

  • If not already paused, click Pause first.
  • Then click Cancel Batch.
  • Confirm the cancellation.

All QUEUED URLs are marked CANCELLED. Any tabs still IN_PROGRESS finish and their status becomes the actual outcome (COMPLETED or FAILED); nothing is retroactively cancelled.

4. What Happens To Reserved Credits

When you started the batch, credits were provisionally reserved for the estimated cost. On pause or cancel:

  • Actually consumed credits stay consumed. These are the ones for URLs that succeeded.
  • Reserved-but-unused credits are released back to your balance immediately.

You are never charged for URLs that were not sent.

5. Pause Vs Cancel: Which To Pick

  • Pause if you plan to come back to this batch within a few hours. The queue stays intact.
  • Cancel if you want to stop entirely, or if you want to change the agent, or if you want to start a different batch.

Cancelled batches show up in Import Jobs with status CANCELLED and can be resumed later; see the article on Import Job resumption.

6. Long Pauses

A paused batch stays paused as long as the extension is open. If you close Chrome or restart the computer:

  • The paused batch is preserved in your local extension storage.
  • When you reopen the extension, the queue is still there.
  • Click Resume to continue.

Very long paused batches (over 30 days) are cleared automatically to prevent storage buildup.

7. Pausing From The Dashboard

If the extension is closed on the device that started the batch:

  • Sign in to your dashboard.
  • Go to Import Jobs.
  • Find the IN_PROGRESS job.
  • Click Pause.

The pause signal reaches the extension within a few seconds. Note that this only works if the browser running the batch is currently open; a closed browser cannot be paused remotely.

Not every URL results in a successful submission. Failures are normal; typical batches finish with 15% to 40% of URLs in FAILED state depending on target quality. Here is what causes them and what happens when they hit.

1. What Is Not Charged For Failures

The core rule: you are not charged a website credit for a failed URL. Failure detection is designed to be strict; if there is any doubt about whether the form was submitted, ContactID errs on the side of “failed” so you keep your credit.

Specifically, no credit is consumed if:

  • The form was not found on the page.
  • The submit button was found but rejected the submission (server error, captcha).
  • The page loaded but ContactID could not identify a contact form.
  • The tab timed out before submission completed.

2. The Common Failure Reasons

Every FAILED URL has a specific reason attached. The most common:

  • Form not detected. No contact form on the page.
  • Bot detection. Cloudflare, hCaptcha, or reCAPTCHA blocked the submit.
  • Required field could not be filled. File uploads, custom dropdowns, or unusual field types that the extension does not handle.
  • Page load timeout. Site took over 90 seconds to load.
  • Network error. Submission never got a response.
  • Site returned an error. 500-class server error after clicking Submit.
  • Redirect loop. The page redirected too many times without settling.
  • Blocked domain. ContactID has blocklisted this domain (rare; see the blocklist article).

3. Seeing Why A URL Failed

  • Click the FAILED URL row in the Queue view or Activity list.
  • The detail panel shows the reason and (when available) a screenshot of the page state at failure.
  • Some failures include a suggestion (e.g., “This site has hCaptcha; try again with the Manual Send option”).

4. Retry Logic

Failed URLs are not retried automatically within the batch. Once a URL is FAILED, the batch moves on.

You can trigger a retry manually:

  • Filter the Queue view to FAILED.
  • Select the URLs you want to retry.
  • Click Retry Selected.

Retried URLs run through the pipeline again with the current agent. Failures on retry are treated as new failure records; the URL keeps its full history.

5. Batch-Level Failure Behavior

If failures pile up in a running batch, ContactID may intervene automatically:

  • Circuit breaker. If 20 URLs fail in a row, ContactID pauses the batch and shows a warning (“Unusually high failure rate detected”). See the circuit breaker article.
  • Rate-limit fallback. If failures are caused by hitting a rate limit at the target site, ContactID slows down automatically to avoid making it worse.

6. Reducing Failure Rate

Typical actions that lower failure rate over time:

  • Clean your list better before importing (remove non-web URLs, social pages).
  • Segment by industry so you can tune your approach for platforms that fail more.
  • Update the extension to get the latest form-detection improvements.
  • Use the Test Send feature (single URL) before running large batches on a new type of site.

7. Failures And Reply Rate

Failure rate and reply rate are related but not the same:

  • A batch with 40% failure rate but a 3% reply rate on successful sends is better than a batch with 5% failure rate and 0.5% reply rate.
  • Look at replies, not just failures. Failures are unavoidable; replies are the actual outcome.

When a form submission fails, ContactID does not automatically retry within the same batch, but it does support manual retries and per-URL retry limits. Here is exactly how retry logic works.

1. No Automatic Retries In A Running Batch

By design, a URL that fails during a batch is marked FAILED and the batch moves on. There is no automatic retry.

Two reasons for this choice:

  • Failure reasons are usually not transient. If Cloudflare blocked us the first time, it will block us the second time. Retrying wastes time and looks aggressive to the target.
  • Batch throughput matters. Retrying every failure would slow batches dramatically.

2. Manual Retry From The Queue View

After a batch finishes (or during a pause):

  • Filter the Queue view to FAILED status.
  • Check the boxes next to URLs to retry, or click Select All Failed.
  • Click Retry Selected.

Retries run through the pipeline again as if they were new URLs. If the failure was transient (site was down, temporary network issue), the retry may succeed; if the failure was structural (no form on page, permanent captcha), it will fail again.

3. Retry Cost

Each retry attempt is treated as a new send attempt:

  • Successful retry consumes one website credit.
  • Failed retry does not.
  • AI Personalization runs again if enabled, spending AI wallet again.

4. Retry Limits Per URL

A single URL can be retried up to five times before ContactID marks it as “permanently failed” and refuses further retries. The Retry button is greyed out on such URLs.

The 5-retry cap prevents you from wasting AI budget hammering a URL that structurally cannot succeed.

5. Bulk Retry From Import Jobs

For a whole batch’s worth of failures:

  • Go to the Import Job’s detail view.
  • Click Retry All Failed.
  • Confirm the retry.

This re-queues every FAILED URL in the job as a new mini-batch. It runs with whatever agent is active on the extension at retry time (which may be different from the original batch’s agent).

6. Retry Delay

There is no built-in delay between the original failure and the retry. However, ContactID does enforce a cooldown between attempts on the same URL:

  • 10 minute minimum between attempts on the same URL.

Attempting to retry sooner is silently deferred; you can click Retry immediately, but the URL will not be picked up from the queue until 10 minutes have passed since the last attempt.

7. When To Retry Vs When To Skip

Retry when:

  • The failure reason was “network timeout” or “page load timeout” (often transient).
  • The failure was during a period you know the site was having issues.
  • The batch ran during off-hours when target sites can be slow.

Do not retry when:

  • The failure reason was “form not detected” (structural, retrying will not help).
  • The failure reason was “bot detection blocked submission” (structural).
  • You have already tried three or more times.

8. Tracking Retry History

Every URL’s Activity detail shows its retry history:

  • Original attempt timestamp and outcome.
  • Each retry timestamp and outcome.
  • Total retry count.

Useful for spotting URLs that only succeed on the second or third try (indicates a transient issue you might want to schedule around).

The circuit breaker is an automatic safety valve that pauses a batch when failure rates get suspiciously high. It exists to protect you from burning through credits on a broken batch and to protect target sites from unusual traffic patterns. Here is how it works.

1. When The Circuit Breaker Trips

The breaker trips when one of these happens:

  • 20 consecutive failures at the start of a batch.
  • 50 consecutive failures later in a batch.
  • Failure rate exceeds 80% over any 100-URL window during the batch.
  • All submissions to a single domain fail 5+ times in a row (repeat sends to the same target catching a bad state).

When it trips, the batch pauses automatically and you get an alert.

2. Why It Exists

Two failure modes it protects against:

  • A structural batch failure. Something is wrong with your setup (wrong agent, corrupted pitch, bad extension state). The breaker stops you before hundreds of URLs get wasted retries.
  • A network or extension issue. If your internet drops or Chrome starts behaving badly mid-batch, every URL would fail. The breaker catches it early.

Without the breaker, a broken batch could plow through 10,000 URLs, mark them all FAILED (no credit consumed), and eat a full day of AI wallet trying to personalize pitches for pages that never load.

3. Alert Details

When the breaker trips, the alert tells you:

  • Which condition triggered it. So you know what pattern was detected.
  • Failure sample. The last 5 failed URLs and their specific reasons.
  • Suggested action. ContactID’s best guess at what to check.

Common suggestions:

  • “Check your internet connection.”
  • “Reload the extension; local state may be corrupted.”
  • “This looks like a bad URL list; check that the target sites have contact forms.”
  • “The AI wallet is empty; top up before continuing.”

4. What You Do Next

Three options when the breaker trips:

  • Investigate then Resume. Fix whatever caused it and click Resume. The batch continues with the remaining URLs.
  • Cancel the batch. If the diagnosis is bad list or bad agent, cancel and rebuild.
  • Continue anyway. Force the batch to continue despite the warning. Rarely a good idea; if the pattern was real, the next 100 URLs will fail too.

5. Preventing Trips

Habits that avoid tripping the breaker:

  • Clean lists. Well-curated lists have lower failure rates and rarely trip the breaker.
  • Test small before big. Running 20 URLs first surfaces issues before scaling to 2,000.
  • Watch the first 50 sends of a batch, especially with a new list or new agent.
  • Keep the extension updated. Old versions sometimes have bugs that cause spurious failures.

6. False Positives

Occasionally the breaker trips when the batch is actually fine, for example:

  • A list where the first 20 URLs happen to be sites with bot protection.
  • A batch running during a national holiday when many sites are under load.

If you are sure the batch is healthy, click Continue Anyway to override. But if you are unsure, cancel and investigate; the false-positive rate is much lower than the true-positive rate.

7. Configuration

The breaker thresholds are not user-configurable. The values are set based on aggregate ContactID data and tuned to catch genuine problems without excessive false positives.

Enterprise customers can adjust thresholds via support if their use case (e.g., low-quality lists intentionally) makes the default too aggressive.

ContactID auto-appends its signature to every message, but it also checks whether the signature is already present to prevent duplicates. Here is how detection works and what to do if you see two signatures in a message.

1. The Signature Line

Every ContactID send appends this line at the bottom:

Sent via ContactID extension: https://rb.gy/q35m7f

Formatted as small, muted text on a new paragraph.

2. When Auto-Detection Triggers

Before appending, ContactID scans your pitch for existing signature markers. Detection is triggered by any of:

  • The exact string “Sent via ContactID extension”.
  • The rb.gy/q35m7f shortlink.
  • The literal string “Sent via brandID extension” (legacy, from the pre-rename period).
  • Any variant with different casing on those markers.

If detected, ContactID skips appending. The message goes out with exactly one signature.

3. Why This Matters

Two signatures in a single message reads badly:

  • Confuses the recipient about the source.
  • Looks like an editing mistake.
  • Some spam filters flag repeated identical text.

Auto-detection prevents this in the common case where you paste your pitch from a doc that already had the signature line.

4. What The Detection Does Not Catch

Detection is intentionally strict on the specific markers. It does NOT trigger for:

  • A different automated-signature line (“Sent via Outreach Tool” or similar).
  • The words “ContactID” mentioned in the body of your pitch.
  • The words “extension” or “Sent via” appearing alone.

If you write “I loved your recent post on Chrome extensions”, “extension” alone will not trigger detection.

5. Fixing A Doubled Signature

If you see a double signature in a sent message:

  • Open the agent in the dashboard.
  • Remove any signature line from the pitch body.
  • Save.
  • Future sends will have just the auto-appended signature.

Past sends cannot be changed; the double signature stays in your Activity record as-is.

6. Preserving Legacy Sends

If you have historic sends with the old “brandID extension” signature (from before the ContactID rename), those stay as-is in Activity. New sends use the ContactID signature.

Detection recognizes both, so a pasted brandID-era pitch does not double-sign.

7. Can Detection Be Disabled?

No. Detection is on for every account and cannot be turned off. This prevents accidental double-signing at scale.

If you want to intentionally include multiple signatures (rare), you would need to include one variant that does not match the detection markers, but this is discouraged.

Not every contact form can be filled by an extension. Sites with bot protection systems block automated submissions, and ContactID respects that. Here are the systems you will encounter, why they exist, and what ContactID does when it hits them.

1. The Common Protection Systems

These are the ones ContactID recognizes and handles:

  • Cloudflare Turnstile / Challenge. Cloudflare’s standard bot-detection layer, deployed on ~20% of the internet.
  • hCaptcha. Widely-used image or checkbox captcha; often “click all traffic lights” or “I am not a robot”.
  • reCAPTCHA (v2 and v3). Google’s captcha; v2 is checkbox, v3 is invisible scoring.
  • FriendlyCaptcha. A privacy-friendly captcha increasingly used in the EU.
  • Custom bot heuristics. Some sites detect via behavioral signals (mouse patterns, form fill timing, header signatures) rather than an explicit captcha.

2. ContactID’s Policy

ContactID does not solve captchas or bypass bot protection. When a protection layer is detected:

  • The URL is marked FAILED with reason “Bot detection blocked submission”.
  • No credit is consumed.
  • No further attempt is made on this URL in the current batch.

This is deliberate. Bypassing bot protection is technically against most sites’ terms of service and can get your IP blocked. ContactID is designed for legitimate B2B outreach, and legitimate outreach respects the site’s expressed preferences.

3. How ContactID Detects Bot Protection

Detection uses multiple signals:

  • Explicit widgets on the page (Cloudflare iframe, hCaptcha script tag).
  • Response codes from the submit endpoint (403 with Cloudflare-signature).
  • Post-submit page content that indicates challenge (redirect to a captcha page).
  • Known Cloudflare/hCaptcha URL patterns.

If any signal fires, the URL is marked bot-blocked.

4. What The Failure Detail Shows

Click a bot-blocked FAILED URL to see:

  • Which protection system was detected.
  • Whether the block happened before submission or after.
  • Whether the site is generally hostile to automated submissions or if this was a transient captcha challenge (which sometimes only fires for repeat visitors).

5. Should You Retry?

Usually not. Bot detection is a structural block, not a transient error. Retrying the same URL:

  • Uses another attempt from the URL’s 5-retry limit.
  • Consumes AI wallet if AI Personalization is on.
  • Rarely succeeds.

An exception: transient challenges (Cloudflare sometimes fires a challenge on a first visit and lets a second visit through). Retry once, no more.

6. Removing Bot-Protected Sites From Your List

To keep your list efficient, remove known bot-protected domains before importing:

  • Sites hosted on Cloudflare (about 20% of the internet) that have Turnstile enabled.
  • Sites explicitly using hCaptcha or reCAPTCHA on their contact forms.
  • Government, banking, and healthcare sites (almost always have captcha).

You can flag these in your CRM by testing a single URL first with the extension’s Test Send feature.

7. Alternative Contact Methods

For sites that are bot-protected:

  • Email directly. If the site publishes a contact email address, use it via your normal email tool.
  • LinkedIn outreach. For B2B, LinkedIn DMs bypass site-level bot protection.
  • Manual submission. Nothing prevents you from opening the site, filling the form by hand, and submitting. ContactID just does not automate this.

Bot detection is a signal from the site owner about their preferred communication channel. Respect it.

Still stuck? We’re happy to help.

Install the extension, sign up, or reach out to support directly.

Back to Help Center