Disclaimer prawny. Ten artykuł dotyczy wyłącznie pobierania publicznie dostępnych danych. W USA Computer Fraud and Abuse Act (CFAA) kształtuje granice legalności scrapingu, a w UE GDPR ogranicza przetwarzanie danych osobowych. Zawsze sprawdzaj robots.txt, Terms of Service i lokalne przepisy przed rozpoczęciem prac.
Najlepsze API do web scrapingu 2026: co warto wiedzieć na start
Jeśli szukasz najlepszego API do web scrapingu 2026, prawdopodobnie stoisz przed wyborem: zapłacić za managed scraping API, które zdejmie z Ciebie obsługę proxy, JS rendering i CAPTCHA — czy zbudować własny stos na residential proxy i zachować pełną kontrolę nad kosztem i architekturą. Obie droże mają sens, ale przy różnych wolumenach i typach celów wygrywa inna opcja.
Managed scraping API to endpoint, do którego wysyłasz URL, a w odpowiedzi dostajesz gotowy HTML lub JSON. Dostawca w tle zarządza rotacją IP, renderowaniem JavaScript (często przez headless Chrome), rozwiązywaniem CAPTCHA i ponowami. Ty płacisz per request albo per credit. To wygodne, ale przy milionach requestów miesięcznie koszt rośnie liniowo, a mnożniki za renderowanie JS i premium proxy potrafią wynieść 5x–75x bazowej ceny.
Z drugiej strony masz samodzielny stos: Twój scraper (requests, Playwright, Scrapy) + pula residential proxy z rotacją. Tu płacisz za ruch (GB) lub per IP, a nie per request. Przy 10 mln requestów miesięcznie różnica może być rzędu wielkości. W tym artykule porównamy pięciu wiodących dostawców scraping API z podejściem build-it-yourself na ProxyHat.
Co dokładnie robi scraping API — i dlaczego problem w ogóle istnieje
Nowoczesne strony nie są statycznym HTML. React, Vue, Angular — wszystko renderuje się po stronie klienta. Do tego dochodzi anti-bot: DataDome, Kasada, PerimeterX, Cloudflare Bot Management. Każde z tych rozwiązań analizuje fingerprint przeglądarki, TLS signature, behavioral patterns i reputację IP.
Scraping API rozwiązuje ten problem, udostępniając warstwę abstrakcji:
- URL in, HTML out — wysyłasz
GET https://api.scraper.com/?url=example.com, dostajesz HTML. - Rotacja proxy — dostawca ma pulę tysięcy IP residential i mobilnych, rotuje per request.
- JS rendering — headless Chrome lub Playwright uruchamia stronę, czeka na DOM, zwraca wynik.
- CAPTCHA handling — integracja z 2Captcha, Anti-Captcha lub własne solvery.
- Geo-targeting — wybór kraju, czasem miasta.
Samodzielny stos replikuje to samo, ale Ty zarządzasz każdym elementem. Zamiast ?render=true uruchamiasz Playwright. Zamiast ?country=US ustawiasz user-country-US w username proxy. Zamiast płacić 10 creditów za request, płacisz za transfer GB.
Kryteria oceny scraping API w 2026
Success rate na chronionych celach
To najważniejsze kryterium. Success rate = procent requestów zwracających 200 + poprawny HTML (nie challenge page). Na niezabezpieczonych stronach każdy dostawca osiąga 95%+. Różnice pojawiają się przy DataDome, Kasada i PerimeterX:
- DataDome — wymaga TLS fingerprint pasującego do realnej przeglądarki i residential IP.
- Kasada — heavy JS obfuscation, wymaga pełnego renderowania i czasem mobilnego IP.
- PerimeterX — behavioral analysis, blokuje headless bez stealth patchów.
Dostawcy scraping API różnią się tu znacząco. ScrapingBee i ZenRows inwestują mocno w anti-bot bypass, ale ich mnożniki creditów dla premium targets sięgają 25x–75x. ScraperAPI ma oddzielne endpointy dla JS rendering (5x) i premium proxy (10x–25x).
Model cenowy
Dwa dominujące modele:
- Per-request flat — jeden request = jeden credit, niezależnie od typu. Proste, ale drogie przy JS rendering.
- Credit multipliers — bazowy request = 1 credit, JS render = 5x, premium proxy = 10x–25x, CAPTCHA = dodatkowe credity. Elastyczne, ale trudne do budżetowania.
Przykład: 1000 requestów z JS rendering na premium proxy może kosztować 25 000 creditów zamiast 1000. Przy planie 100 000 creditów/mc ($49/mc) to wyczerpuje cały miesięczny budżet w 4 dni.
Geo-targeting i concurrency
Geo-targeting określa, z jakiego kraju pojawi się Twój request. Większość dostawców obsługuje country-level, niektórzy city-level (Bright Data, Zyte). Concurrency = liczba jednoczesnych requestów. ScraperAPI domyślnie daje 5 concurrent na planie starter, Zyte 50, ScrapingBee zależy od planu. ProxyHat nie narzuca limitu concurrency — ogranicza Cię tylko przepustowość puli IP.
Porównanie: ScraperAPI vs Zyte vs Bright Data vs ScrapingBee vs ZenRows vs ProxyHat DIY
| Dostawca | Model cenowy | JS render (mnożnik) | Premium proxy (mnożnik) | Geo-targeting | Concurrency | Success rate (chronione cele) |
|---|---|---|---|---|---|---|
| ScraperAPI | Per-request / credit | 5x–10x | 10x–25x | Country | 5–50 (plan) | Średni–wysoki |
| Zyte | Per-request | Wliczone | Wliczone | Country | 50+ | Wysoki |
| Bright Data Web Scraper / SERP API | Per-request + CPM | Wliczone | Wliczone | Country + city | Wysoki | Bardzo wysoki |
| ScrapingBee | Credit multipliers | 1x (wliczone) | 5x–25x | Country | Plan-dependent | Wysoki |
| ZenRows | Credit multipliers | 1x | 5x–75x | Country | Plan-dependent | Wysoki |
| ProxyHat DIY | Per GB / per IP | Samodzielnie (Playwright) | Residential domyślnie | Country + city | Bez limitu | Zależy od implementacji |
Ceny i mnożniki na podstawie publicznie dostępnych planów dostawców na początku 2026. Sprawdź aktualne cenniki przed decyzją.
Cost crossover: gdzie wygrywa API, a gdzie ProxyHat
Cost crossover to punkt, w którym koszt managed API przestaje być opłacalny względem samodzielnego stosu proxy. Zależy od trzech zmiennych:
- Wolumen requestów — poniżej 100 000/mc, API wygrywa na wygodzie i kosztach stałych.
- Udział JS rendering — jeśli 80% requestów wymaga renderowania, mnożniki 5x–25x drastycznie podnoszą koszt API.
- Success rate — niższy success rate = więcej ponowień = więcej creditów. Przy 60% success rate na trudnym celu, 1000 poprawnych wyników kosztuje ~1667 creditów zamiast 1000.
Praktyczna granica: przy powyżej 1 mln requestów/mc z umiarkowanym JS rendering, samodzielny stos na residential proxy jest zazwyczaj 3–10x tańszy. Poniżej 100 000/mc, koszt deweloperski zbudowania i utrzymania własnego scrapera przewyższa oszczędności na proxy.
Rozbiór kosztów per GB
Scraping API typowo przelicza się na ~$2–$5 per 1000 requestów (bazowych). Przy JS rendering i premium proxy rośnie do $10–$50 per 1000 poprawnych wyników. ProxyHat residential proxy kosztują ułamki dolara per GB — a 1000 requestów HTML to typowo 50–200 MB transferu. Sprawdź aktualne ceny na stronie cennika ProxyHat.
Praktyczny przykład: pobranie chronionej strony przez API i przez ProxyHat
Opcja A — ScrapingBee (managed API)
import requests
API_KEY = "YOUR_SCRAPINGBEE_KEY"
url = "https://example-protected-site.com"
response = requests.get(
"https://app.scrapingbee.com/api/v1/",
params={
"api_key": API_KEY,
"url": url,
"render_js": "true",
"country": "us",
},
timeout=30,
)
print(response.status_code, len(response.text))
# Koszt: ~5 creditów (JS render) = ~$0.005 per request
# Per 1000 requestów: ~$5Opcja B — Python requests + ProxyHat residential proxy
import requests
proxies = {
"http": "http://user-country-US:pass@gate.proxyhat.com:8080",
"https": "http://user-country-US:pass@gate.proxyhat.com:8080",
}
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 "
"(KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36",
"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
"Accept-Language": "en-US,en;q=0.9",
}
response = requests.get(
"https://example-protected-site.com",
proxies=proxies,
headers=headers,
timeout=30,
)
print(response.status_code, len(response.text))
# Koszt: ~0.1 MB transferu per request
# Per 1000 requestów: ~100 MB = ułamki dolara przy cenach per GBJeśli strona wymaga JS rendering, zamień requests na Playwright z tym samym proxy:
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
browser = p.chromium.launch(
proxy={
"server": "http://gate.proxyhat.com:8080",
"username": "user-country-US",
"password": "pass",
},
headless=True,
)
page = browser.new_page()
page.goto("https://example-protected-site.com", wait_until="networkidle")
html = page.content()
print(len(html))
browser.close()Wersja curl dla szybkiego testu:
curl -x "http://user-country-US:pass@gate.proxyhat.com:8080" \
-H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)" \
-H "Accept: text/html" \
"https://example-protected-site.com"Wersja SOCKS5 (port 1080):
curl --socks5 "user-country-US:pass@gate.proxyhat.com:1080" \
"https://example-protected-site.com"Porównanie kosztu per 1000 requestów
| Podejście | Koszt per 1000 (bazowe) | Koszt per 1000 (JS render) | Koszt per 1000 (premium) |
|---|---|---|---|
| ScrapingBee | ~$2 | ~$5–$10 | ~$25–$50 |
| ZenRows | ~$2 | ~$5 | ~$25–$75 |
| ScraperAPI | ~$2 | ~$5–$10 | ~$10–$25 |
| ProxyHat DIY | ~$0.05–$0.50 | ~$0.05–$0.50 + CPU | ~$0.05–$0.50 |
Szacunki na podstawie publicznych cenników i średniego rozmiaru strony ~100 KB. Rzeczywiste koszty ProxyHat zależą od planu — zobacz cennik.
Sticky sessions i geo-targeting w ProxyHat
Scraping API często oferuje session_id dla sticky sessions. ProxyHat robi to samo przez flagę w username:
# Sticky session (ten sam IP przez wiele requestów)
http://user-sid-abc123-country-US:pass@gate.proxyhat.com:8080
# City-level geo-targeting
http://user-country-US-region-new_york-city-new_york_city:pass@gate.proxyhat.com:8080
# Per-request rotation (domyślnie — brak flagi session)
http://user-country-US:pass@gate.proxyhat.com:8080Pełna lista lokalizacji dostępna na stronie lokalizacji ProxyHat.
Kiedy NIE używać scraping API
Managed scraping API nie jest złotym młotkiem. Oto sytuacje, w których samodzielny stos na ProxyHat jest lepszym wyborem:
- Wysoki wolumen (>1 mln requestów/mc). Przy 5 mln requestów z JS rendering, różnica między $5 per 1000 (API) a $0.20 per 1000 (ProxyHat) to $24 000 vs $1 000 miesięcznie.
- Custom parsing i transformacje. Scraping API zwraca surowy HTML. Parsing i tak robisz sam. Jeśli masz złożone pipeline'y (Scrapy + item pipelines + deduplikacja), API nie dodaje wartości.
- Pełna kontrola nad retry logic. Chcesz retry tylko na 503, nie na 403? Chcesz exponential backoff z jitterem? Samodzielny stos daje pełną kontrolę.
- Niestandardowe nagłówki i TLS fingerprint. Scraping API narzuca własny fingerprint. Jeśli potrzebujesz curl-impersonate lub konkretnego TLS JA3, musisz hostować samodzielnie.
- Dane wrażliwe / compliance. Niektóre API logują URL-e w celach debugowania. Przy danych podlegających GDPR nie chcesz, by URL trafił do logów dostawcy.
- Streaming i long-polling. Scraping API ma timeout (typowo 60 s). Jeśli pobierasz strumieniowo lub nasłuchujesz WebSocket, potrzebujesz bezpośredniego proxy.
Kiedy scraping API ma sens
- MVP i prototypy. Chcesz szybko zwalidować pomysł bez inwestycji w infrastrukturę.
- Niski wolumen (<100 000/mc). Koszt deweloperski przewyższa oszczędności.
- Bardzo trudne cele (Kasada, DataDome). Dostawcy API inwestują w anti-bot bypass, którego replikacja jest czasochłonna.
- Zespół bez doświadczenia proxy. API uczy się w godzinę, samodzielny stos w dniach.
Najczęstsze błędy i edge case'y
- Ignorowanie mnożników creditów. Plan „100 000 creditów/mc” znaczy 100 000 bazowych requestów — ale z JS rendering to 20 000, a z premium proxy 4000.
- Zbyt wysoka concurrency. 100 równoległych requestów na jeden cel = flaga anti-bot. Zacznij od 5–10 i monitoruj.
- Niespójne nagłówki. User-Agent Chrome + Accept-Language
ja-JP+ IP z Niemiec = flaga. Dopasuj wszystko do jednej tożsamości. - Brak retry z rotacją IP. Po 403 nie retryuj tego samego IP — rotuj i spróbuj ponownie.
- Ignorowanie robots.txt. Nawet jeśli nie jest prawnie wiążące, etycznie powinieneś je szanować.
Gotowy przetestować ProxyHat na swoim scrapingu? Sprawdź cennik i dokumentację, albo zobacz przypadek użycia SERP tracking.
