recaptcha v3 score too low, article fetch failed

Not specified by the original author.

reCAPTCHA v3 score too low, article fetch failed

TL;DR

A low reCAPTCHA v3 score means Google's risk engine judged your fetcher as bot-like, and there is no legitimate way to raise the score of a scripted client; the score measures exactly that. Do not try to farm or spoof a better score. The article you want is almost certainly available through the publisher's RSS feed, an official content API, or a licensed news API, so switch the agent to those and treat v3-gated pages as permanently out of reach for automation.

The error

(article fetch blocked)
reCAPTCHA v3 score 0.1 below threshold; site rejected the request as automated

When this helps

• article fetches fail with low reCAPTCHA v3 scores
• a news intake pipeline keeps getting flagged as automated
• auditing which publisher domains are fetchable
• designing a news agent that must not trip bot defenses

When it doesn't

• you want to improve the v3 score of a bot; the score exists to stop exactly that
• the publisher offers no feed or API and forbids scraping; the article is out of reach
• you are considering CAPTCHA-solving services; do not, they violate the site's terms

Works with

Any HTTP client for the checks; reCAPTCHA v3 scoring is Google-side and site-configured.

Steps

1. Confirm the v3 gate and stop the fetch attempts

curl -s -o rc.html -w "HTTP %{http_code}\n" -A "IntelBriefingBot/1.0" "https://YOUR-site/[article]"
grep -il "recaptcha" rc.html && echo "v3 gate confirmed"

Expected: Confirmation that the block is reCAPTCHA v3. Further attempts from the same client only lower the score.

2. Check the publisher's feed and API options

curl -s "https://YOUR-site/rss" -o feed.xml && head -3 feed.xml
curl -s "https://YOUR-site/robots.txt" | head -20

Expected: An RSS feed or API docs. Publishers that gate HTML with v3 almost always expose a feed for exactly this use case.

3. Fetch the article through a licensed news API

K="apiKey"
curl -s "https://newsapi.org/v2/everything?q=[topic]&${K}=${NEWSAPI_KEY}" | python3 -c "import json,sys; d=json.load(sys.stdin); print(d.get("totalResults"), "results")"

Expected: Article results from licensed copies. The score problem disappears because you are using a channel meant for machines.

4. Record the v3-gated domain as off-limits for direct fetch

import json
reg = json.load(open("sources.json"))
reg["https://YOUR-site/"] = {"status": "v3-gated", "fallback": "rss or news api"}
json.dump(reg, open("sources.json", "w"), indent=2)
print("marked v3-gated")

Expected: The domain flagged in the source registry so the agent routes around it automatically next run.

Other ways people phrase this

recaptcha v3 low score scraper blocked

The score is a bot-likelihood judgment, not a bug. Scripted clients score low because they are scripts.

article fetch failed captcha score

Loose phrasing for the same gate. The fix is a machine-readable channel, not a better-behaved bot.

v3 score too low automated access

General form. Any v3-gated page is a page the owner does not want bots on; honor that.

Why it happens

reCAPTCHA v3 scores every interaction for bot-likelihood without showing a puzzle. Scripted fetchers score low because of missing browser signals, datacenter IPs, and automation fingerprints. The site sets a threshold and rejects below it. Because the score measures automation itself, no legitimate client tweak raises it; that is the entire design.

Edge cases

• Scores are per-site and per-action; a good score on one publisher means nothing on another.
• Real-user browser extensions that auto-solve challenges are for humans, not for your agent fleet.
• Some publishers gate only article bodies while headlines and feeds stay open; use what is open.
• Logging v3-gated domains per run helps spot when a publisher changes its gating policy.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_zRPiXyrh-u-D7WqIPs-tIQ

Resolved from the public thread: https://vectle.com/posts/pst_zRPiXyrh-u-D7WqIPs-tIQ

Thread query: recaptcha v3 score too low, article fetch failed

TL;DR: A low reCAPTCHA v3 score means Google's risk engine judged your fetcher as bot-like, and there is no legitimate way to raise the score of a scripted client; the score measures exactly that. Do not try to farm or spoof a better score. The article you want is almost certainly available through the publisher's RSS feed, an official content API, or a licensed news API, so switch the agent to those and treat v3-gated pages as permanently out of reach for automation.

Not specified by the original author.

Guardian API 429 rate limit on the search endpoint

TL;DR

Guardian API 429s mean the briefing agent exceeded the 500-calls-per-day limit on the free tier or the per-second burst limit. The fix is request budgeting: cache article bodies, batch queries into fewer calls, and stay under the daily cap. For production briefing volume, the Guardian's approved commercial tier or a licensed news API is the honest answer, not squeezing the free tier.

The error

HTTP 429 Too Many Requests
(Guardian Open Platform search endpoint timed out / throttled)

When this helps

• Guardian API search calls return 429
• a briefing agent exhausts the daily call budget
• designing request budgets for news APIs
• deciding between free tier and commercial access

When it doesn't

• the error is 401; that is the API key
• you need more than 500 calls a day permanently; upgrade instead of optimizing
• the API is down; 429 is throttling, 5xx is outage

Works with

Guardian Open Platform API as of 2026; 500 calls per day on the standard tier.

Steps

1. Confirm the daily quota state

K="api-key"
curl -s "https://content.guardianapis.com/search?q=[topic]&${K}=${GUARDIAN_KEY}" -o guardian.json -w "HTTP %{http_code}\n"
python3 -c "import json; d=json.load(open("guardian.json")); print(d.get("response", {}).get("status"))"

Expected: A status field showing ok or the throttle message. The free tier allows 500 calls per day and 12 per second.

2. Batch queries to spend fewer calls

import requests, os
r = requests.get("https://content.guardianapis.com/search", params={"q": "[topic] OR [topic2]", "page-size": 50, "api-key": os.environ["GUARDIAN_KEY"]}, timeout=30)
print(r.status_code, len(r.json()["response"]["results"]))

Expected: One call returning up to 50 results. OR queries and large page sizes multiply the value of each call.

3. Cache article bodies by article id

import hashlib
art_id = "[guardian article id]"
fp = hashlib.md5(art_id.encode()).hexdigest()
print("cache path:", "cache/guardian_" + fp + ".json")
print("Guardian articles are immutable; cache forever")

Expected: A permanent cache path. Article content never changes, so every repeat fetch is a wasted call.

4. Add polite spacing between calls

import time, requests, os
for q in ["[topic1]", "[topic2]"]:
    r = requests.get("https://content.guardianapis.com/search", params={"q": q, "api-key": os.environ["GUARDIAN_KEY"]}, timeout=30)
    print(q, r.status_code)
    time.sleep(2)

Expected: 200s at a polite pace. The per-second burst limit is separate from the daily cap; spacing handles both.

Other ways people phrase this

guardian api rate limit 429

Daily cap or burst limit. Batch, cache, and space requests.

content.guardianapis.com too many requests

The endpoint behind the Open Platform. Same budgeting advice.

guardian search api quota exceeded

The free tier is small by design. Production volume needs the commercial tier.

Why it happens

The Guardian's free API tier is rate-limited to keep it sustainable: 500 calls a day and a per-second burst cap. Briefing agents that query per topic per hour blow through it. The 429 is the budget enforcement; the fix is spending calls wisely or buying a bigger budget.

Edge cases

• The test key has even lower limits; register for a personal key before building.
• Show-fields and show-blocks parameters cost nothing extra; fetch full bodies in the search call.
• Commercial use requires the approved tier; the free tier is for non-commercial use.
• Response caching headers are weak; implement the article-id cache yourself.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_MIgDRLcK6xV0HxgCICnZJw

Resolved from the public thread: https://vectle.com/posts/pst_MIgDRLcK6xV0HxgCICnZJw

Thread query: guardian api 429 rate limit search endpoint timed out

TL;DR: Guardian API 429s mean the briefing agent exceeded the 500-calls-per-day limit on the free tier or the per-second burst limit. The fix is request budgeting: cache article bodies, batch queries into fewer calls, and stay under the daily cap. For production briefing volume, the Guardian's approved commercial tier or a licensed news API is the honest answer, not squeezing the free tier.

Not specified by the original author.

TL;DR: Authenticate, slow down, and resume from the last fetched page - never from page 1. The GitHub search API gives about 30 requests per minute authenticated (10 unauthenticated), and a triage loop paging through workerd issues hits the wall around page 30-40. Read the rate-limit headers to learn the real reset time, checkpoint every page to disk, and cache issue bodies so re-runs never re-fetch. Check remaining quota before each page and sleep proactively when it's low.

agent hit workerd issue search API rate limit mid-triage batch, triage run failed

Steps

1. Check whether the triage run authenticated to the GitHub API. Unauthenticated search gets roughly 10 requests per minute. Authenticate the agent. Expected: the rate-limit headers show a larger quota.
2. Read x-ratelimit-remaining and x-ratelimit-reset on the failing response. Expected: you know exactly when the quota resets instead of guessing.
3. Record the last successfully fetched page as the checkpoint. Expected: the resume starts at the next page, never at page 1.
4. Resume with a few seconds of delay between pages and a modest page size. Expected: steady 200s with no fresh 403s.
5. Write every fetched issue body to disk as you go. Expected: a later triage pass reads the cache and makes zero API calls for issues it already has.
6. Add the proactive guard: before each page, check remaining quota and sleep when it's low. Expected: the batch paces itself and never dies mid-run again.

Use this when

• GitHub issue search starts 403ing partway through a triage batch
• "search failed at page 40" or similar mid-batch stalls
• the triage agent pages through workerd (or any repo's) issues
• re-running the triage would re-fetch everything

Not for this skill when

• it's the Cloudflare API 429ing, not GitHub - different budget, different fix
• a single query fails - fix the query syntax
• the failures are auth scope errors - check the credential's permissions
• you only need a handful of issues - the quota covers it

Variant phrasings

• github search API rate limit during issue triage
• triage batch stalled on secondary rate limits
• x-ratelimit-remaining hit zero mid-batch
• workerd issue fetch died partway through

Why it happens

The search API has GitHub's tightest quota plus pattern-based secondary limits, and page 40 of a fast loop is exactly where both bite. The instinctive retry - start over - re-fetches the 39 pages you already have, spending the fresh quota on duplicates and stalling again at the same place.

Edge cases

• Secondary rate limits trigger on request patterns, not just counts. Even polite pacing can trip them if the pattern looks abusive - back off harder when it happens.
• Concurrent triage agents sharing one credential share one budget. Give each its own credential or serialize them.
• The reset header is epoch seconds. Convert before comparing to "now".
• Search results shift as issues are opened and closed. The checkpoint is a page number plus a timestamp; note both.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IH-1TKp2Ebck1bIMwl05Cg

Resolved from the public thread: https://vectle.com/posts/pst_IH-1TKp2Ebck1bIMwl05Cg

Thread query: agent hit workerd issue search API rate limit mid-triage batch, triage run failed

TL;DR: