Web scraping med strukturerad JSON och hur nya API-typen fungerar

Vill du skrapa en webbsida och få tillbaka färdig, typad JSON i stället för HTML som du själv måste tolka? Det är precis det som en ny generation av web scraping-API:er försöker lösa. Du definierar ett schema med fältnamn, datatyp och ett exempelvärde. API:et hämtar sidan, extraherar datan och returnerar ett objekt du kan använda direkt.

Det låter banalt. Men det är ett rätt fundamentalt skifte från hur webbskrapning fungerat de senaste tio åren.

Vad ett traditionellt scraper-API faktiskt gör

De flesta etablerade tjänsterna löser ett enda problem: att hämta sidan. De roterar proxyer, kör headless-browsers, hanterar Cloudflare och returnerar HTML till dig.

Sen är det ditt jobb.

Du sitter där med en sträng på 300 KB och ska skriva selektorer i BeautifulSoup, Cheerio eller Playwright. När sajten ändrar sin layout, vilket händer ofta, går din parser sönder utan att du märker det förrän datan blir tom eller fel. Du bygger alltså en lagerkaka: API:et hämtar, din kod tolkar, din databas lagrar. Tre ställen där saker kan gå sönder.

Om du är ny på vad ett API egentligen är rekommenderar jag att börja med grunderna kring API:er innan du dyker djupare.

Skiftet från schema till JSON-utdata

Den nya modellen byter ut HTML-svaret mot strukturerad data direkt. Du skickar något i stil med:

”`json

{

”url”: ”https://exempel.se/produkt/123”,

”schema”: {

”namn”: { ”type”: ”string”, ”example”: ”Sneakers” },

”pris”: { ”type”: ”number”, ”example”: 899 },

”lager”: { ”type”: ”boolean”, ”example”: true }

}

}

”`

Tillbaka får du ett rent JSON-objekt med exakt de fälten, redan typade. Ingen parsning. Ingen efterbehandling. Ingen kod som ska underhållas när sajten byter klassnamn på sina prisetiketter.

Under huven används en språkmodell som läser den renderade sidan och plockar ut värdena som matchar schemat. Det är detta som gör att samma anrop fungerar mot en webbshop, en nyhetsartikel eller en jobbannons utan att du behöver skriva ny logik.

Skillnaden märks direkt när du börjar bygga något i produktion. En integration som tidigare krävde två dagars selektorarbete blir en eftermiddag.

Varför effektiviteten ofta blir bättre

Påståenden om ”6-7 gånger effektivare” än konkurrenterna är värda att granska kritiskt, det beror helt på vad man mäter. Men det finns några reella faktorer som drar ner kostnaden:

• Färre misslyckade anrop. När extraktionen sker server-side och valideras mot schemat slipper du anrop som returnerar tom data
• Mindre dataöverföring. JSON med fem fält är hundratals gånger mindre än en full HTML-sida
• Inga separata ”credits” för olika features. Traditionella tjänster tar ofta 5-75 credits för ett JS-renderat anrop och 1 credit för ett enkelt, det gör prissättningen oförutsägbar
• Mindre kod att underhålla. Den dolda kostnaden i scraping är inte API-avgiften, det är utvecklartid

Den sista punkten är den största. Du sparar inte 50 öre per anrop. Du sparar fyra timmar i veckan på att laga sönderbruten parsing.

Vad du faktiskt kan bygga med det

Användningsfallen är desamma som tidigare, bara enklare att komma igång med:

Prisbevakning mot konkurrenters webbshoppar. Sammanställning av jobbannonser från flera plattformar. Insamling av öppna data från svenska myndighetssidor där det inte finns något publikt API. Aggregering av nyheter eller fastighetsannonser till en egen tjänst.

Just det sista är intressant. Många svenska sajter saknar fortfarande öppna API:er trots att informationen är publik. Hemnet, Blocket och flera kommunsidor är klassiska exempel där utvecklare i åratal har byggt egna lösningar.

Det juridiska kring webbskrapning

Här blir det viktigt att vara nykter. Att skrapa en webbsida är inte automatiskt lagligt bara för att tekniken är smidig.

Datainspektionen (numera Integritetsskyddsmyndigheten) har varit tydlig med att personuppgifter omfattas av GDPR även när de hämtas från publika sidor. Skrapar du namn, e-post eller andra identifierande data utan rättslig grund, då har du ett problem oavsett hur snyggt JSON-svaret ser ut.

Tre saker att kolla innan du skrapar något:

1. Sajtens villkor. Många förbjuder explicit automatiserad åtkomst
2. robots.txt. Inte juridiskt bindande, men ett tydligt signalvärde
3. Vilken typ av data. Aggregerad statistik är något helt annat än personuppgifter

För rena tekniska data, produktpriser, väderdata, börskurser, är riskerna oftast små. För allt som rör individer: var försiktig.

När du inte ska använda ett scraper-API

Det finns en frestelse att lösa allt med ett snyggt nytt verktyg. Gör inte det.

Om sajten du vill hämta data från har ett öppet API, använd det. Det är snabbare, billigare och stabilare. SCB, Trafikverket, Naturvårdsverket och en lång rad andra svenska aktörer publicerar data via vanliga REST-endpoints. Att skrapa deras webbsidor i stället är att göra livet onödigt krångligt för sig själv.

Är det en engångskörning på en handfull sidor? Skriv ett litet Python-script med requests och BeautifulSoup. Du behöver ingen tjänst.

Är volymen riktigt hög och datan komplex? Då börjar LLM-baserad extraktion kosta, varje anrop drar tokens hos modellen som körs i bakgrunden. För skrapning i miljonklassen kan en handskriven parser fortfarande vara billigare per anrop.

Vad du bör titta efter när du jämför tjänster

Om du står inför valet mellan flera leverantörer:

Prissättningsmodellen är viktigare än listpriset. En tjänst som kostar 0,01 dollar per anrop men tar 50 credits för ett JS-renderat anrop kan i praktiken bli dyrare än en som tar 0,03 dollar flat rate. Räkna på dina faktiska anrop, inte på marknadsföringspriset.

Schemavalidering. Returneras tomma fält eller felaktiga datatyper utan varning? Det är värre än ett rent fel, du upptäcker problemet först när din databas är full av skräp.

JS-rendering ingår eller inte. Många moderna sajter laddar innehåll med JavaScript efter att HTML:en levererats. Utan rendering får du en tom sida.

Stealth-funktioner. Hur tjänsten hanterar Cloudflare, anti-bot-system och CAPTCHA avgör om den faktiskt fungerar mot de sajter du bryr dig om.

Det här är en del av en större trend

LLM-driven dataextraktion dyker upp på fler ställen än bara skrapning. Du ser samma mönster i verktyg som omvandlar dokument till strukturerad data, i kundtjänst-bottar som plockar ut intent från fritext, och i hur AI förändrar kodningsarbetet generellt.

Det gemensamma: att låta en modell tolka ostrukturerad input mot en känd struktur är otroligt mycket billigare nu än för två år sedan. Det öppnar för verktyg som inte var ekonomiskt rimliga tidigare.

Web scraping är bara ett av många områden som påverkas. Men det är ett där förändringen är konkret nog att du kan testa själv på en eftermiddag, och se direkt om det förändrar hur du bygger.