Web Scraper CAPTCHA Solving with DeathByCaptcha in C#

A crawler that meets a web scraper CAPTCHA on every page is not slow because your parser is slow. On 13 August 2026 DeathByCaptcha's own status page put the average reCAPTCHA solve at 16 seconds. Ten thousand protected pages at that rate is more than 44 hours of waiting if you solve them one after another, plus $28.90 in fees at the posted $2.89 per 1,000. Your parsing runs in milliseconds. Everything else is queue.

That arithmetic decides the shape of the code. A solver call is not a function call. It is a network job with a queue in front of it and an expiry date behind it, and the C# around it has to be written as if that were true. Treat it like int.Parse and you get a working demo and a pipeline that fails at three in the morning.

This guide covers the DeathByCaptcha side of the work: how to submit a challenge from C#, how to get an answer back, and the point at which the answer stops being worth anything. Code below was written against the official .NET client 4.7.1, published to NuGet on 12 March 2026, and Selenium.WebDriver 4.47.0, published 10 August 2026. Every price, type number and parameter name here was read from the vendor's own documentation on 13 August 2026.

One thing up front. The cheapest web scraping CAPTCHA is the one you never trigger. Avoidance gets its own section near the end, and on most projects it moves the bill further than any line of code below.

What you are buying, and what you are not

A solving service is an API with a queue. You submit a challenge, you poll, you get an answer. Under the hood DeathByCaptcha runs a mix of OCR models and human workers; its FAQ claims "over 17 years" of operation and "average solving time around 10—12 seconds". The three-step submit, poll, use loop has not changed in that time. What changed is what comes back at the end of it.

Text answers and token answers are different products. For a distorted-text image you get characters, and you type them into a field. For reCAPTCHA, hCaptcha, Turnstile and every other modern challenge you get a token, and the token is a bearer credential with a fuse burning. Google's own verification documentation states that each response token "is valid for two minutes, and can only be verified once", and returns timeout-or-duplicate when you miss the window. Cloudflare gives Turnstile tokens 300 seconds and says plainly that a token "can only be validated once". hCaptcha documents single use with a short window as well.

Put those two facts side by side. The vendor advertises a 16 to 19 second reCAPTCHA solve. The token lives 120 seconds. That leaves roughly a hundred seconds of margin on a good day, and rather less when the queue is busy. Nothing in the API tells you how much of the fuse has already burned when the answer lands in your hand.

The token is not a session. It proves that something passed a challenge for a given site key on a given page. It does not carry cookies, it does not carry a clearance, and on score-based systems it is judged partly on the IP that requested it. A token minted through a datacentre address and submitted from a residential proxy is two different stories told to the same verifier.

Which client, and the name collision that will bite you

DeathByCaptcha ships nine official client libraries. The .NET one is on NuGet, MIT licensed, and targets net6.0, net8.0 and net10.0:

dotnet add package DeathByCaptcha --version 4.7.1

There are two transports behind one interface. DeathByCaptcha.HttpClient talks to https://api.dbcapi.me/api over TLS. DeathByCaptcha.SocketClient opens a plain TCP connection to api.dbcapi.me on ports 8123 to 8130. The socket transport is the lower-latency option and the one older tutorials reach for, including the earlier version of this article. It is also unencrypted, and it authenticates with your account username and password rather than a revocable key. Unless you have measured a latency problem, use the HTTP client. The vendor's own Selenium sample does.

Now the collision. DeathByCaptcha.HttpClient and System.Net.Http.HttpClient are both called HttpClient. Any file that has using System.Net.Http; and using DeathByCaptcha; at the top will refuse to compile on new HttpClient(...) with CS0104, an ambiguous reference. The official README dodges it by writing the type out in full, and so should you:

using DeathByCaptcha;

// Fully qualified on purpose: System.Net.Http.HttpClient has the same short name.
Client client = new DeathByCaptcha.HttpClient(username, password);

// Better still, if you have generated one in the account panel:
// Client client = new DeathByCaptcha.HttpClient("authtoken", tokenFromPanel);

The authtoken form is worth the two minutes it takes to set up. It is the only way to keep your account password out of process memory, out of environment files and out of whatever your CI logs.

Three things about this library that the sample code does not tell you.

Verbose defaults to true. The base Client writes a line to the console for every call, prefixed with DateTime.Now.Ticks, so production logs fill with raw tick counts like 639222192000000000 POLL. Set client.Verbose = false; unless you enjoy that.

There is no Task-based API. Every Decode overload either blocks the calling thread inside Thread.Sleep or hands you a callback delegate. Twenty concurrent solves means twenty parked threads, each sleeping through a 16 second queue.

Version 4.7.0 removed a global certificate validation bypass. The changelog records it under Security: the old client turned off server certificate checks for the whole process, not for its own connections. If any project of yours still references a 4.6.x zip from the vendor's download page, that is a process-wide TLS hole sitting underneath every other HTTPS call your scraper makes. Upgrade before you read any further.

Solving a classic image CAPTCHA

Classic distorted text still shows up on logins, older government portals and small e-commerce back ends. You need the image bytes. If the challenge is a plain <img src="...">, download it with an ordinary HTTP client that shares your scraper's cookie container, because a fresh session gets a fresh, different image.

If you are already driving a browser, take the element's screenshot. Selenium's .NET WebElement implements ITakesScreenshot directly, so the old routine of screenshotting the page and cropping by pixel coordinates is dead weight:

using OpenQA.Selenium;
using OpenQA.Selenium.Chrome;

using var driver = new ChromeDriver();
driver.Navigate().GoToUrl("https://example.com/protected");

// WebElement implements ITakesScreenshot, so no cropping math is required.
var captchaEl = driver.FindElement(By.Id("captcha"));
byte[] imageBytes = ((ITakesScreenshot)captchaEl).GetScreenshot().AsByteArray;

The cast compiles because ITakesScreenshot is an interface and FindElement returns IWebElement. It succeeds at runtime because the concrete WebElement implements it. Against a driver that does not, you get an InvalidCastException rather than a compile error, so keep the call in a try block if you support more than one browser.

Then hand the bytes over:

using DeathByCaptcha;

Client client = new DeathByCaptcha.HttpClient(username, password);
client.Verbose = false;

// GetBalance() returns US cents, not dollars. 250.0 means $2.50.
Console.WriteLine($"Balance: {client.GetBalance() / 100:C}");

Captcha result = client.Decode(imageBytes, Client.DefaultTimeout);   // 60 seconds
if (result != null)
{
    Console.WriteLine($"Solved #{result.Id}: {result.Text}");

    driver.FindElement(By.Name("captcha_code")).SendKeys(result.Text);
    driver.FindElement(By.Name("submit")).Click();

    // If the site rejects it, report the bad solve within the hour.
    if (!driver.PageSource.Contains("SUCCESS"))
        client.Report(result);
}
else
{
    Console.WriteLine("No usable answer: timed out, or came back marked incorrect.");
}

The null check is the whole check. Older versions of this walkthrough tested result.Solved && result.Correct after the null test, and that is redundant. Decode(byte[], int, Hashtable) is one line in the library: return this.Poll(this.Upload(img, ext_data), timeout);. Poll returns the captcha only when captcha.Solved && captcha.Correct, and returns null otherwise. A non-null return already means both flags are set. What the null does not tell you is which of the two failure modes you hit, a timeout or a bad answer, so log the distinction yourself if you care.

Report bad solves, and report them fast. The FAQ is explicit that you are not billed for wrong answers, and equally explicit about the deadline: errors must be reported within "an hour (60 minutes)" of submission. A nightly batch that verifies solves the next morning refunds nothing. client.Report(captcha) calls Report(captcha.Id) under the hood, which POSTs to captcha/{id}/report.

Balance is in cents. GetBalance() returns a double of US cents, which is why the snippet above divides by 100. Printing it raw is how people convince themselves they have $412 of credit when they have $4.12.

reCAPTCHA v2, where the model changes

This is the step that trips people. With reCAPTCHA you never send an image. You send the site key, a public value baked into the page, and the page URL. The service does the interaction on its own infrastructure and returns a g-recaptcha-response token. You put the token where the page expects it and submit.

The site key sits on the widget element:

var widget  = driver.FindElement(By.CssSelector(".g-recaptcha, [data-sitekey]"));
var siteKey = widget.GetDomAttribute("data-sitekey");
var pageUrl = driver.Url;

A note on that method name, because bad advice circulates. GetAttribute was marked obsolete in Selenium .NET 4.27.0 and the deprecation was reverted in 4.28.0. In the current bindings neither GetAttribute nor GetDomAttribute carries an [Obsolete] attribute, and the official documentation still shows GetAttribute in its C# example. Both work. GetDomAttribute reads the literal HTML markup while GetAttribute merges attribute and property, and for data-sitekey that difference never bites. Use whichever your codebase already uses and ignore anyone who tells you the build is broken.

With the library, a token job is a Hashtable of a type number and a JSON payload:

using System.Collections;
using System.Text.Json;

var tokenParams = JsonSerializer.Serialize(new Dictionary<string, string>
{
    ["googlekey"] = siteKey,
    ["pageurl"]   = pageUrl
});

var job = new Hashtable
{
    ["type"]         = 4,             // 4 = reCAPTCHA v2 token
    ["token_params"] = tokenParams
};

Captcha solution = client.Decode(Client.DefaultTokenTimeout, job);   // 120 seconds

Client.DefaultTokenTimeout is 120. The reCAPTCHA token is valid for 120 seconds. Those two numbers being equal is not a coincidence and it is not a comfort: a solve that arrives at second 118 hands you a token with two seconds of life. Pass a shorter timeout, 60 or 75 seconds, and treat a miss as a retry rather than as an answer. A token you cannot spend is worth the same as no token.

The same job over raw HTTP

The library is a thin wrapper, and there are reasons to skip it: no dependency, full control of concurrency, or a stack that is not .NET. The endpoint is https://api.dbcapi.me/api/captcha:

using System.Net.Http;
using System.Text.Json;

static async Task<string> SolveRecaptchaV2(System.Net.Http.HttpClient http,
                                           string user, string pass,
                                           string siteKey, string pageUrl)
{
    var tokenParams = JsonSerializer.Serialize(new
    {
        googlekey = siteKey,
        pageurl   = pageUrl
    });

    // 1. Submit. type 4 = reCAPTCHA v2 token.
    var submit = new FormUrlEncodedContent(new Dictionary<string, string>
    {
        ["username"]     = user,
        ["password"]     = pass,
        ["type"]         = "4",
        ["token_params"] = tokenParams
    });

    // Without this header the API answers in key=value text, not JSON.
    http.DefaultRequestHeaders.Accept.ParseAdd("application/json");

    var created = await http.PostAsync("https://api.dbcapi.me/api/captcha", submit);
    if ((int)created.StatusCode == 403)
        throw new InvalidOperationException("403: bad credentials or empty balance.");

    var doc = JsonDocument.Parse(await created.Content.ReadAsStringAsync()).RootElement;
    int id  = doc.GetProperty("captcha").GetInt32();

    // 2. Poll. Keep the interval above two seconds.
    for (int i = 0; i < 20; i++)
    {
        await Task.Delay(3000);

        var poll = await http.GetAsync($"https://api.dbcapi.me/api/captcha/{id}");
        var pd   = JsonDocument.Parse(await poll.Content.ReadAsStringAsync()).RootElement;

        if (pd.TryGetProperty("text", out var t) &&
            t.ValueKind == JsonValueKind.String &&
            t.GetString() is { Length: > 0 } token)
            return token;                       // the g-recaptcha-response token
    }
    throw new TimeoutException("reCAPTCHA not solved inside the token's useful life.");
}

Four details in there are worth more than the rest of the snippet.

Accept: application/json is not decoration. Leave it off and the API replies with a key-value body that JsonDocument.Parse will reject. The official client sets it on every request.

The submit may answer with a redirect. DeathByCaptcha's own .NET transport contains explicit handling for 303 See Other on these calls, following the Location header to the created record. A stock .NET HttpClient follows redirects by default and re-issues a 303 as a GET, so the response you parse is usually already the polled record. Disable AllowAutoRedirect and you have to read Location yourself.

403 means two different things. The library throws AccessDeniedException for it, and the API returns it both for wrong credentials and for an empty balance. Alerting on "auth failure" when the real problem is a $0 account costs an hour of the wrong debugging.

Poll no faster than the service tolerates. The shipped client walks the intervals {1, 1, 2, 3, 2, 2, 3, 2, 2} and then settles at 3 seconds, under a source comment reading "Keep if above 2 seconds or you might be banned for too abusive polling." The comment and the array disagree with each other in the first two entries. Three seconds is a safe floor, and at a 16 second average it costs you nothing.

Getting the token onto the page

The response goes into the hidden g-recaptcha-response textarea. Use .value, not .innerHTML:

var token = solution.Text;

((IJavaScriptExecutor)driver).ExecuteScript(
    "document.getElementById('g-recaptcha-response').value = arguments[0];",
    token);

// Invisible widgets and most AJAX forms need the callback fired as well.
var callback = widget.GetDomAttribute("data-callback");
if (!string.IsNullOrEmpty(callback))
    ((IJavaScriptExecutor)driver).ExecuteScript($"{callback}(arguments[0]);", token);

driver.FindElement(By.CssSelector("button[type=submit]")).Click();

The earlier version of this article set innerHTML. That is the kind of mistake that passes a manual test and fails in production. For a <textarea>, innerHTML writes the element's default value; the value property only follows it while the field has never been touched. DeathByCaptcha's own Selenium sample in the .NET repository assigns .value, and so does every widget's real callback.

Two more things about that block. getElementById returns one element, and a page can render more than one widget, so on multi-widget pages query the textarea inside the form you are actually submitting. And if you are not driving a browser at all, skip Selenium entirely: POST the token as the g-recaptcha-response field alongside the form's other values, including every hidden input, the anti-forgery token and __VIEWSTATE on ASP.NET. That path is faster, cheaper and how most production scrapers work.

v3, Enterprise, Turnstile, hCaptcha: what actually changes

The earlier version of this article said your integration code barely moves between challenge types. That is true of the shape and false of the details, and the details are what the compiler and the API argue about. Each family has its own type number and its own parameter field, and the JSON key for the site key is not the same twice:

Every one of those payloads also accepts proxy and proxytype. On Enterprise the proxy is not optional; the token API documentation requires one. The remaining families, GeeTest, DataDome, Lemin, Capy, MTCaptcha, Cutcaptcha, Friendly Captcha, Amazon WAF, Cyber Siara, Tencent and ATB, each get their own *_params field, all of them listed in the published OpenAPI specification. Their type numbers are not stated on the pages we read, so read them from the example file for your language rather than guessing.

reCAPTCHA v3 needs two extra fields and a different mental model. You pass action, the name the page declares in grecaptcha.execute(...), and min_score. The vendor's sample uses 0.3, which is low. A site that enforces 0.7 will verify that token successfully and still turn you away. Because v3 scores the requester rather than the challenge, high-quality residential proxies matter more here than anywhere else. A token minted from a flagged address scores badly no matter who solved it. DeathByCaptcha also gives v3 tokens a shorter shelf life than v2, one minute against two.

hCaptcha is the claim to check for yourself. Comparison articles list it under DeathByCaptcha. A recent recheck of the field concluded the opposite. Both were reading real evidence, because the vendor's own site says both things at once. The homepage price table does not mention hCaptcha. Neither does the supported-types list on the API index, nor the OpenAPI spec, which defines fourteen *_params fields and none for hCaptcha. The .NET examples folder ships no hCaptcha sample. And yet the hCaptcha page is live, documents type=7 with an hcaptcha_params payload of sitekey, pageurl, proxy and proxytype, carries a "Status: OK" indicator, and quotes a price: "price is $3.99/1K Hcaptcha challenges correctly solved." All of that was true on 13 August 2026. Documented but unadvertised is the honest reading. Test it against your own target before you plan a project around it.

FunCaptcha is genuinely gone. There is no type for it, no parameter field, and deathbycaptcha.com/api/funcaptcha answers 404. The only trace left is an unused funcaptcha.jpeg sitting in the examples folder of the .NET client. Comparisons that still credit the service with Arkose support are copying each other.

Turnstile and hCaptcha need their own field names on the page, too. Cloudflare injects an input named cf-turnstile-response into the form; hCaptcha uses h-captcha-response. Neither is g-recaptcha-response, and a token written into the wrong element is silently ignored by the page and rejected by the verifier.

Where the two-minute token breaks your pipeline

A single script gets away with anything. The failures below only appear once the same code runs ten thousand times a night.

Queue time eats the token, not your code. You solve, you queue the result behind a retry backoff or a rate limiter, you submit forty seconds later, and Google returns timeout-or-duplicate. The log says the token was invalid. The token was fine when it was minted. Solve as late as possible in the request path, ideally as the last thing before the POST, and never solve a batch of tokens up front.

Blocking Decode calls burn threads, not CPU. Each one parks a thread inside Thread.Sleep for the length of the queue. At twenty in flight that is twenty threads doing nothing for sixteen seconds each. The .NET thread pool grows grudgingly once it is past its minimum, so a burst of solves produces latency that looks like the service being slow when it is your own pool starving. Wrap the client in Task.Run with a bounded SemaphoreSlim, or drive the raw HTTP endpoint with real async and skip the library for high-concurrency work.

One HttpClient, reused, with a connection lifetime. Microsoft's HttpClient guidelines spell out both traps: a new instance per request exhausts ports, since "TCP ports aren't released immediately after connection closure", while a permanent static instance never re-resolves DNS, because "HttpClient only resolves DNS entries when a connection is created". A static client built on a SocketsHttpHandler with PooledConnectionLifetime set to about fifteen minutes solves both. For a job that solves CAPTCHAs for hours, the DNS half is the one that catches you.

The IP that solves should be the IP that submits. Score-based systems bind the token loosely to the requester. Pass the same proxy into token_params that your scraper uses for the form POST. Mismatched addresses are the most common cause of a token that "solved correctly" and was rejected anyway.

Balance failures look like network failures. Zero balance returns 403, the same code as bad credentials, and the library raises the same AccessDeniedException. Poll GetBalance() on a schedule and alert on the number rather than waiting to decode the exception.

Report inside the hour or eat the cost. The refund path exists, and it expires. Wire the verification result back into Report in the same run, not in a nightly reconciliation job.

What it costs, in numbers

Read from the vendor's homepage and FAQ on 13 August 2026, per 1,000 successfully solved:

Two things fall out of that table. Audio is the cheapest route on any form that offers it, at roughly a fifth of the visual price, and legacy login forms offer it far more often than people expect. And the coordinate and image-group APIs now cost more than the token API they were meant to replace, so there is no reason left to use them.

For comparison, read the same day: 2Captcha's pricing page lists image at $0.5–$1, reCAPTCHA v2 at $1–$2.99, v3 at $1.45 for a score of 0.3 or below and $2.99 above it, and Turnstile at $1.45. DeathByCaptcha's flat $2.89 sits at the top of that range on reCAPTCHA and roughly double it on Turnstile. The full field, with coverage by challenge type, is in our roundup of CAPTCHA solving services.

Advertised speeds are counters, not commitments. Three pages of the same vendor's site, read within an hour of each other on 13 August 2026, disagreed with one another. The homepage said 2 seconds for normal CAPTCHAs, 19 for reCAPTCHA and 15 for other types. The FAQ said 2, 19 and 10. The status page said 3, 16 and 7. None of it is a service level agreement, none of it is measured on your targets, and the only number that matters is the one your own logs produce after a week.

Cost per page is the number to plan against, and it is not the price per solve. A crawl of 50,000 pages that triggers reCAPTCHA on 8% of them buys 4,000 solves, which is $11.56. The same crawl at a 60% challenge rate, which is what an unrotated datacentre IP earns you, buys 30,000 solves for $86.70 and adds roughly 133 hours of serialised waiting. The gap between those two bills is proxies and pacing, not solver choice.

Don't solve what you can avoid

Every solved CAPTCHA costs money and adds 3 to 60 seconds of latency. Cut the number you trigger and everything else improves at once.

Rotate good proxies. This is the whole game, and the rest of this list is footnotes to it. Most challenges fire because too many requests came from one address, or from an address whose reputation was spent by somebody else months ago. A pool of rotating residential proxies makes each request look like a different ordinary visitor, and on score-based systems it also raises the score of the tokens you do have to buy. Datacentre ranges are cheap because they are pre-judged. If you are choosing between spending another $200 a month on proxies and another $200 a month on solves, the proxies buy speed as well: a request that is never challenged costs one page fetch, not one page fetch plus sixteen seconds of queue.

Slow down, and jitter. Human pacing trips fewer defences than a tight loop.

Look like a browser that exists. Headless detection is a common trigger. A properly configured headless browser with a coherent user agent, viewport and timezone avoids many challenges outright.

Keep sessions. Once a site trusts a session it challenges it less. Reuse cookies rather than starting cold on every request.

CAPTCHAs are one layer of a larger anti-scraping stack, and the layers are correlated: whatever flagged you into a challenge is also rate-limiting you, fingerprinting you and logging you. Solvers are for the residue.

Migrating an integration you already have

DeathByCaptcha's least discussed feature is that it speaks other services' protocols. Alongside its own socket and HTTP interfaces it hosts compatibility layers for the Antigate, 2Captcha and DeCaptcher schemes. For anyone maintaining C# that already talks to one of those, switching provider is a base address change rather than a rewrite.

The 2Captcha-compatible endpoints are api.deathbycaptcha.com/2captcha/in.php and .../res.php, with the same methods and parameters as the real thing. The documentation is explicit that the difference is authentication: the key field becomes your_dbc_username:your_dbc_password. Unsupported challenge types answer with ERROR_URL_METHOD_FORBIDDEN.

That credential format deserves a warning. Your account password travels in a query parameter, which means it lands in proxy logs, in browser history if anyone tests by hand, and in any APM tool that captures URLs. The vendor documents the endpoint as http://. The host does answer over TLS: a request to https://api.deathbycaptcha.com/2captcha/res.php returned an HTTP 401 rather than a connection failure when we checked on 13 August 2026, which is the response you would expect for a bogus key. Force the scheme to https and treat the compatibility layer as a bridge rather than a destination.

The DeCaptcher layer is the same story in an older dialect, and it is now the only surviving piece of a service that no longer exists; we traced what happened to it in the DeCaptcher review. If your C# is built around 2Captcha's own library rather than raw HTTP, the 2Captcha integration walkthrough covers that API in the same detail as this page covers this one. For Python and Scrapy pipelines the same three-step loop applies with different syntax, as in our Scrapy series, and the general C# scraping setup is in web scraping with C#.

The change log is a decent proxy for whether the service is being tended. The most recent entry, 13 May 2026, is about cryptocurrency payments through a new processor. The one before it, 15 April 2026, records library upgrades and new C++ and Go clients. The .NET repository's last release is 12 March 2026. This is a maintained product with a modest release cadence, not an abandoned one.

Where this stops working

Solving is not access. A token gets you past one gate. Anti-bot products that guard a whole site, rather than one form, hand out a clearance cookie once the challenge is passed and tie it to the session and fingerprint that earned it. Buy the token in one browser profile, submit it from another, and you have paid $0.00289 to be blocked in a new way.

Enterprise raises the floor. reCAPTCHA v2 Enterprise needs type 25, a different parameter field and a mandatory proxy. Sites on Enterprise generally also score server-side signals you cannot influence from a solver.

Local OCR only pays on simple images. For classic distorted text at high volume, a trained local model beats $1.39 per 1,000. Below a few hundred thousand solves the setup and retraining time costs more than the fees. Above that, and only if the images are simple, it is worth measuring.

The legal boundary is not technical. Using a solving service is not inherently illegal. It can still breach a site's terms of service, and the data behind the wall carries its own legal considerations. Scrape public data, respect robots.txt and rate limits, take advice on anything sensitive.

And the plumbing compounds. Solver accounts, proxy pools, fingerprint upkeep and a token expiry budget are four moving parts that each fail differently, and none of them are your data. Teams that would rather receive rows than run that stack hand it to a web scraping service or take the output as a managed data feed instead.

Get the small things right and the CAPTCHA stops being the interesting problem. Fully qualify DeathByCaptcha.HttpClient. Send the right type number and the right parameter field. Write the token into .value and fire the callback. Solve late, submit immediately, report failures within the hour, and keep the solving IP and the submitting IP the same. Then go spend the afternoon on your proxies, because that is where the bill actually lives.