Running Campaigns

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 submission.

1. Prerequisites.

• Signed into the extension. Check the side panel; you should see your queue, not a sign-in screen.
• URLs in the queue. From an import, a paste, or a saved list. If empty, add URLs first via importing target websites.
• Website credits. Free tier starts with 30. Paid plans include their monthly quota plus any extras. If balance is zero, buy credits before starting.

2. Pick the active agent. Open the side panel, click the agent switcher at the top, and pick the agent for this batch. The agent decides the pitch, sender profile, and AI personalization behavior used for every URL in the run. See agents and profiles.

3. Confirm concurrency setting. Default is 5 concurrent tabs. Change under Settings if you want faster or slower processing. See the “Concurrent Tabs” article below.

4. Click Start Batch. The extension opens the first N tabs (N = your concurrency), runs the fill script on each, submits, and moves on to the next batch of tabs.

5. Credits are charged as sends succeed. Nothing is pre-charged or reserved when you click Start. A credit is deducted only at the moment a form is successfully submitted. If you have fewer credits than queued URLs, the batch sends what your credits cover and then stops automatically.

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

The four URL statuses.

• PENDING (Queued). In the list, not yet started. Waiting for a tab slot to open.
• SENT (In Progress). The URL is currently open in a tab; the fill script is running.
• COMPLETED. Form was found, filled, and submitted successfully. One credit was consumed.
• FAILED. The URL was attempted but did not complete. Reason shown on click; no credit consumed.

Batch-level state.

• Running: tabs are cycling through the queue.
• Paused: you clicked Pause; tabs currently In Progress finish, no new ones open.
• Stopped: you clicked Stop; the batch ends. URLs not yet attempted stay in PENDING and are picked up by your next batch.

No per-day submission quota. Pacing is controlled by your concurrency setting and human-like typing between fields, not by any per-day cap. See monitoring results to review completed sends afterward.

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

1. Default and range. Default is 5 concurrent tabs. The slider ranges from 1 to 8.

2. Where to change it.

1. Open the extension side panel.
2. Click the Settings icon (top right).
3. Adjust the Max Concurrent Tabs slider.
4. Save. The new setting takes effect on the next tab opened.

3. What each level does.

• 1 tab. One URL at a time. Slowest but easiest on memory. Good for 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.
• 4 to 5 tabs (default zone). The sweet spot for most users on modern hardware. Good throughput, memory manageable.
• 6 to 8 tabs. Maximum speed. Uses noticeably more RAM; leave other apps closed. Success rate may drop slightly if some target sites are slow to render.

4. Combining with human-like typing. Even at 8 concurrent tabs, ContactID types fields character-by-character with random micro-pauses. This mimics human input and helps avoid bot detection on sites with anti-bot protection.

Pausing lets you take a break without losing your queue. Stopping ends the batch entirely.

1. Pause from the extension.

1. Open the side panel.
2. Click Pause in the top right of the Queue view.
3. All new tabs stop opening. Tabs currently In Progress finish their current form.
4. The batch enters Paused state.

2. Resume from pause. With the batch paused, the button changes to Resume. Click it and the concurrency window fills again; the batch continues from where it left off. You can pause and resume as often as you want, no cost or penalty.

3. Stop a batch. To end the batch entirely:

1. Pause first (optional but cleaner).
2. Click Stop.
3. The batch ends immediately. URLs already Completed or Failed keep their status.
4. Unprocessed URLs return to Pending in your queue for your next batch.

4. What happens to credits. ContactID never reserves credits at batch start, so pausing or stopping has zero credit implications. You were only charged for each successful submission that already happened. No credits to “release” or refund.

The queue itself is preserved across pause, stop, and even browser restart. See monitoring results to review what was sent.

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.

1. You are not charged for failures. Core rule: a credit is only consumed on a successful submission. Failure detection is 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 charged 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. Common failure reasons.

• No contact form on the page. The URL was a homepage, blog post, or product page without a form.
• Cloudflare or bot detection. The site presented a challenge page instead of rendering. See troubleshooting for handling.
• Captcha. The form has a reCAPTCHA or hCaptcha that requires human action.
• Login required. The form is behind an authenticated area.
• Timeout. The page took too long to render; the tab was closed before submission completed.
• Field mismatch. Required fields could not be detected or matched to your agent profile.

3. Reviewing failures. Click any Failed URL in the queue to see the specific reason. Common patterns:

• If captcha errors are frequent, your list has many aggressive-anti-bot sites; clean the list.
• If timeout errors are frequent, try lowering concurrency (see article above).
• If “no form found” is frequent, your list has too many blog / product pages instead of true contact pages.

4. Retrying failures. Failed URLs can be re-added to your queue via the Retry action in the Activity log (see monitoring results).

ContactID has two layers of retry: automatic within a batch, and manual after.

1. Automatic retry within a batch. Some transient failures trigger a single automatic retry before marking the URL as Failed:

• Network timeout during initial page load
• Tab closed unexpectedly
• Content script failed to inject on first attempt

Retries happen immediately in a fresh tab. If the retry also fails, the URL is marked Failed permanently for that batch.

2. What is NOT auto-retried.

• Cloudflare / captcha blocks (retrying would fail the same way)
• “No form found” errors (retrying would fail the same way)
• Server errors from the target site (500, 503)

3. Manual retry after the batch. Failed URLs remain in the Activity log. From there you can:

• Re-queue individual failures using the Retry action
• Export all failures to CSV and re-import them later (useful if you want to fix your agent or wait for target site issues to resolve)

See monitoring results for how to work with failed URLs.

The circuit breaker automatically pauses a batch if failure rates spike, protecting you from wasting a run on a broken configuration or a bad target list.

1. Trigger condition. If more than 15 URLs in a row fail, or the overall failure rate in the current batch exceeds 80% after at least 20 attempts, the circuit breaker trips and pauses the batch automatically.

2. Why this exists. Runaway failures usually mean:

• Your target list has systemic quality issues (all social media URLs, all aggregator pages).
• Your agent profile is misconfigured (missing required field).
• Your account has been signed out and the fill script is not authenticated.

Rather than burn through the entire queue, the batch pauses so you can investigate.

3. What to do when tripped.

1. Open the last few Failed URLs and read their failure reasons.
2. Fix the underlying issue (clean the list, update the agent, re-sign in).
3. Resume the batch, or Stop and re-import a cleaner list.

4. Resetting. The circuit breaker resets automatically when you resume, or manually via the Reset Breaker button in Settings.

See troubleshooting for common configuration issues that trigger the breaker.

Some contact forms have a “message” field that already contains a template like “Hello, my name is [Name]”. ContactID detects these and prevents your pitch from being pasted on top of the existing text.

1. What is detected. Common signature patterns:

• “Sent from my iPhone / Android”
• Pre-filled greetings like “Hello, my name is…”
• Auto-populated signature lines from a website’s own form builder

2. What happens on detection. ContactID:

• Detects the existing text pattern in the message field.
• Clears it before typing your pitch.
• Types your agent’s pitch fresh.

This avoids the awkward “Hello, my name is [Name]” prefix landing on your recipient.

3. When it might miss. Very custom signature patterns not covered by the built-in detector may slip through. If you see a form failing consistently or landing with weird prefixes, report the URL via troubleshooting so the pattern can be added.

See agents and profiles for how your pitch and signature interact with the fill script.

Many websites use Cloudflare, hCaptcha, or reCAPTCHA to block automated form submissions. ContactID has different strategies for each.

1. Cloudflare “Just a moment…” pages.

• ContactID waits up to 15 seconds for the challenge to resolve on its own (most Cloudflare basic challenges do).
• If it does not resolve, the URL is marked Failed with reason “Cloudflare challenge”.
• These sites cannot be automated without human interaction and are best filtered from your target list.

2. reCAPTCHA and hCaptcha.

• ContactID does not solve captchas. Ever.
• If a captcha is detected on the form, the URL is marked Failed with reason “Captcha required”.
• These forms need human completion.

3. Invisible bot detection (fingerprinting). ContactID uses human-like typing patterns (character-by-character with pauses), realistic mouse movement simulation on submit clicks, and randomized field-fill order. This gets past most basic detection but not sophisticated fingerprinting.

4. Ethical use. ContactID is built for reaching businesses that publish contact forms specifically to be contacted. It does not attempt to defeat sites that clearly do not want automated messages. See privacy, data and security.