Match CAPTCHA usage to your workspace balance

API requests authenticate with a workspace API key. Check that workspace when reconciling usage; a shared target hostname doesn’t mean requests belong to the same workspace.

Usage at /usage is labelled last 28 days. It shows Request volume, Successful, Failed (not billed), Average latency, and either Period spend or Unlimited coverage. Don’t infer a matching invoice or the current credit balance from that window alone.

Use By site profile to locate a spike. Compare Site, Share and Requests to find where volume increased, then inspect Success and Billing. These are service usage events, not evidence that the target accepted the resulting requests.

A task with status ready is billed. A failed solve is refunded. Creating a task or receiving an HTTP success response isn’t the same as receiving a usable solution; only ready contains one.

If the solver returns a ready solution but the website rejects the subsequent request, that isn’t a failed solver task. Don’t count it under Failed (not billed) or assume it receives an automatic refund. A replacement task that reaches ready is another billed solve.

The minimum credit deposit is $10; welcome credit is $5. A deposit adds credit to the workspace—it doesn’t describe how much was spent during the usage window. Keep purchased credit and welcome credit separate when comparing your payments with the balance.

Use billed ready tasks—not total request volume—for a pay-as-you-go cost estimate. If the console shows Unlimited coverage, check the applicable product-specific monthly plan instead of pricing all requests as pay-as-you-go. Account credit or an applicable bonus can also change how much additional credit you need.

1. 1.

   Match the affected site and time window

   Use the site-profile breakdown to narrow the search, then compare your application logs over the same period. Record the logical request, its requestId, the returned task ID and the terminal status.

2. 2.

   Look for multiple tasks serving one request

   Several distinct task IDs for one intended solve can explain extra charges if those tasks reach ready. Separate deliberate replacement solves from retries made because a response was lost.

3. 3.

   Recover timed-out creation requests

   A connection timeout doesn’t prove task creation failed. If you have the task ID, retrieve that task. Otherwise, retry the same task request with its original requestId to recover the existing task rather than creating a new logical task.

4. 4.

   Assign requestId before the first attempt

   Use one requestId per intended solve and retain it across retries. It accepts 1–64 ASCII letters, numbers, underscores or hyphens. The same ID with the same task request returns the existing task; using it with different inputs conflicts.

Count distinct tasks when investigating duplicate creation, not just HTTP attempts. Multiple retries returning the same task ID haven’t created multiple tasks.