Case Study7 min read

Scaling Account Registration Across 50 Profiles: A Real Batch Workflow

A team combined unique profile data, automatic CAPTCHA solving, and recovery checks to keep a 50-browser registration run consistent end to end.

Mar 8, 2026

The Scenario

A team needed to register accounts on a platform across 50 antidetect browser profiles. Each account required a unique email, name, phone number, and password. The signup flow included email verification, a reCAPTCHA v2 challenge, and a post-registration onboarding step.

Doing this manually would take 3-4 hours. With Ornold MCP and an AI agent, the entire batch completed in under 25 minutes — including CAPTCHA solving and error recovery.

Preparation: Per-Profile Data

The first step was preparing unique data for each of the 50 profiles. Every field that the signup form required needed a distinct value per session. Reusing data across profiles is the fastest way to get flagged.

The team prepared a dataset with:

Unique email addresses (one per profile, from different providers)
Realistic names matching the profile's locale/language settings
Strong passwords (unique per profile, not sequential)
Phone numbers for SMS verification (from a virtual number service)

Data quality matters more than automation speed. One duplicate email or obviously fake name can trigger fraud detection and flag the entire batch. Invest time in generating realistic, diverse datasets.

// Example profile dataset structure
const profiles = [
  { email: "sarah.mitchell@proton.me", name: "Sarah Mitchell", phone: "+1-555-0142", password: "kR9#mPx2vL" },
  { email: "james.wong@tutanota.com", name: "James Wong", phone: "+1-555-0198", password: "nT4$hQw8bJ" },
  // ... 48 more unique profiles
];

Phase 1: Launch and Navigate

With 50 Linken Sphere sessions ready (each with its own proxy, fingerprint, and timezone), the first step was navigating all of them to the signup page simultaneously.

// Start all sessions and navigate to signup
await browser_list(); // Verify 50 sessions are available
await browser_parallel_navigate({ url: "https://target.example/signup" });

// Wait for the form to load across all sessions
await browser_parallel_wait_for({
  text: "Create your account",
  timeoutMs: 20000
});

48 of 50 sessions loaded the signup page within 8 seconds. Two sessions were slower due to proxy latency — the `wait_for` command held until they caught up at the 14-second mark.

Phase 2: Form Filling

Each session needed its own unique data. Ornold's parallel fill command accepts an array of values that maps 1:1 to active sessions:

// Fill email — each session gets a unique value
await browser_parallel_fill({
  ref: "email",
  values: profiles.map(p => p.email)
});

// Fill name
await browser_parallel_fill({
  ref: "fullname",
  values: profiles.map(p => p.name)
});

// Fill password
await browser_parallel_fill({
  ref: "password",
  values: profiles.map(p => p.password)
});

Form filling across all 50 sessions took about 3 seconds. The DOM-based interaction mode (free, no vision credits) handled the structured form fields without issues.

Phase 3: CAPTCHA Solving

The signup page had a reCAPTCHA v2 challenge. Ornold detected it across all 50 sessions and sent solve requests in parallel:

// Solve CAPTCHAs across all 50 sessions
const captchaResult = await browser_solve_captcha();
// { total: 50, detected: 50, solved: 47, failed: 3 }

47 of 50 CAPTCHAs solved on the first attempt (15-35 seconds). Three sessions failed — the solving service timed out. Instead of retrying the entire batch, the team retried only the failed sessions:

// Retry failed sessions
const retryResult = await browser_solve_captcha();
// Only targets sessions that still have unsolved CAPTCHAs
// { total: 3, detected: 3, solved: 3, failed: 0 }

CAPTCHA solving is the slowest step in most registration flows. Solve after filling the form (not before) to minimize the chance of token expiration.

Phase 4: Submit and Verify

With forms filled and CAPTCHAs solved, the next step was clicking the submit button and verifying that registration succeeded:

// Submit the form
await browser_parallel_click({ ref: "submit" });

// Wait for the success page
await browser_parallel_wait_for({
  text: "Check your email",
  timeoutMs: 15000
});

// Check status
const status = await browser_status();

Results after submission:

46 sessions reached the "Check your email" confirmation page
2 sessions got a secondary security challenge (phone verification prompt)
1 session received a "too many requests" error
1 session timed out during submission

Phase 5: Error Recovery

Instead of restarting the entire batch, the team handled each failure type separately:

Phone verification (2 sessions)

These sessions needed an additional step. The AI agent detected the phone input field, filled in the virtual numbers from the dataset, and submitted. Both sessions completed after SMS verification.

Rate limit error (1 session)

The "too many requests" error was proxy-related — the IP had been used recently. The team switched the session's proxy and retried. Registration succeeded on the second attempt.

Timeout (1 session)

A simple page reload and re-submit fixed this. The form data was still filled in (the browser preserved it), so only the submit action needed to repeat.

Final result: 50 of 50 accounts registered successfully. Total time from first navigation to last confirmation: 23 minutes.

What Made This Work

Several factors turned this from a fragile script into a reliable batch operation:

Per-profile data — Every session had unique, realistic data. No duplicates, no patterns.
Parallel execution — All 50 sessions moved through each phase together, not one at a time.
Selective recovery — Failures were handled per-session, not by restarting the batch. The AI agent identified what went wrong and applied the right fix.
Status checks between phases — `browser_status()` and `wait_for` calls after each step caught divergence early.
CAPTCHA retry logic — Failed solves were retried individually instead of re-solving the entire batch.

Timing Breakdown

Session launch + navigation: ~15 seconds
Form filling (50 sessions): ~3 seconds
CAPTCHA solving (first pass): ~35 seconds
CAPTCHA retry (3 sessions): ~25 seconds
Form submission + verification: ~10 seconds
Error recovery (4 sessions): ~8 minutes
Total: ~23 minutes for 50 accounts

Without the error recovery phase, the happy path for 46 sessions completed in about 2 minutes. Most of the total time was spent on CAPTCHA solving and handling edge cases — which is expected at this scale.

Lessons for Scaling Further

Data quality is the bottleneck, not automation speed. Spend more time on realistic datasets than on optimizing click timing.
Proxy quality directly affects success rate. Cheap shared proxies lead to rate limits and blocks. Residential or mobile proxies perform significantly better.
Don't run more sessions than your machine can handle. 50 Chromium instances need 16-24 GB of RAM. Monitor resource usage and scale hardware before scaling session count.
Build recovery into the workflow from the start. At 50+ profiles, some failures are guaranteed. The question is whether you handle them automatically or manually.
Test with 5 profiles first. Validate the entire flow end-to-end before scaling to 50. Debugging at scale is exponentially harder.
Stagger large batches. Running 100 profiles at once from the same IP range is a red flag. Split into groups of 20-30 with delays between them.

Explainer