Skip to content
Jul 8, 2026

Engineering

Scaling CAPTCHA solving over gRPC

CT

CaptchaSonic Team

Platform Engineering

Most captcha-solving APIs make you do the same dance: POST a task, get an id back, then poll a getTaskResult endpoint every few seconds until a token appears. It works, but every poll is a fresh HTTP round trip, and the gap between "solved" and "you noticed it's solved" is wasted wall-clock time in your automation.

CaptchaSonic's SDKs take a different path: they hold a gRPC connection to our solve infrastructure and stream the result back the moment it's ready.

Why gRPC

  • No poll gap. The server pushes the token as soon as the solve completes, instead of you discovering it on your next poll interval. That shaves seconds off every solve.
  • One connection, many solves. A long-lived HTTP/2 channel multiplexes concurrent solves without re-establishing TLS each time — cheaper per request at high volume.
  • Typed contracts. The request/response schema is generated from the same protobufs the server uses, so the SDK method signatures never drift from the API.

TIP

HTTP REST is still available as a fallback for environments where gRPC is awkward (some serverless platforms). The SDKs pick gRPC by default and fall back transparently.

What it looks like in code

The transport is invisible — you call one typed method and get a token:

from captchasonic import CaptchaSonic

client = CaptchaSonic("sonic_your_key_here")
result = client.solve_recaptcha_v2_token(
    website_url="https://example.com/login",
    website_key="6Le-...",
)
token = result["solution"]["gRecaptchaResponse"]

The SDK handles polling, retries, and error mapping internally, so your automation code stays about solving the page — not about babysitting a task queue.

Where to go next

Back to all articles