TikTok Scraper API: så hämtar du videodata i JSON med jsonscraper

Om en app behöver information om en specifik TikTok-video är det enklast att börja med en enda förfrågan och kontrollera vilka data den returnerar. Därefter kan svaret valideras och förberedas för lagring eller analys.

På sidan för TikTok Scraper API från jsonscraper listas rutter för videor, användare, sökning, hashtaggar, musik och andra datatyper. Nedan går vi igenom den dokumenterade förfrågan getVideoByID och sätt att hantera svaret på ett säkert sätt. Exemplen bygger på leverantörens material. Innan du använder dem bör du testa dem med en giltig nyckel och aktuell dokumentation.

Första förfrågan: hämta videoinformation

I Postman-dokumentationen för getVideoByID anges metoden GET och parametern video_id. Exemplet visar också region och cache_timeout. Basadressen som publicerats på tjänstens sida är https://tiktok.evelode.com.

Exempel på en förfrågan med cURL:

export JSONSCRAPER_LICENSE_KEY="din_nyckel"

curl --get "https://tiktok.evelode.com/getVideoByID" \
  --data-urlencode "video_id=7106855913906081070" \
  --data-urlencode "license_key=$JSONSCRAPER_LICENSE_KEY" \
  --data-urlencode "region=US"

ID:t i exemplet kommer från den publicerade förfrågan. Ersätt det med ID:t för videon du vill kontrollera. Förvara nyckeln i en miljövariabel eller en hemlighetshanterare. Lägg inte in den i ett offentligt kodförråd, klientbaserad JavaScript eller loggar.

Postman beskriver region som en regionkod och anger US som standardvärde. För cache_timeout anger dokumentationen ett standardvärde på 3 600 sekunders cachetid; värdet 0 stänger av cachning. Om du behöver parametern i ditt användningsfall kan du skicka den uttryckligen:

curl --get "https://tiktok.evelode.com/getVideoByID" \
  --data-urlencode "video_id=7106855913906081070" \
  --data-urlencode "license_key=$JSONSCRAPER_LICENSE_KEY" \
  --data-urlencode "region=US" \
  --data-urlencode "cache_timeout=0"

Detta är en anpassning av de parametrar som publicerats för rutten, inte en garanti för att alla svar har samma struktur eller att avstängd cachning passar alla uppgifter. Kontrollera autentisering och parametrar mot den aktuella samlingen innan du inför lösningen: Postman kan skicka nyckeln via en konfigurerad API Key, medan cURL-exemplet ovan visar den som en URL-parameter.

Samma förfrågan i Python

Nedan visas en variant med Pythons standardbibliotek. Den skapar en GET-förfrågan, skickar parametrarna och hanterar nätverksfel, HTTP-fel och ogiltig JSON.

import json
import os
from urllib.error import HTTPError, URLError
from urllib.parse import urlencode
from urllib.request import Request, urlopen

base_url = "https://tiktok.evelode.com/getVideoByID"
license_key = os.environ.get("JSONSCRAPER_LICENSE_KEY")

if not license_key:
    raise RuntimeError("Ange miljövariabeln JSONSCRAPER_LICENSE_KEY")

params = {
    "video_id": "7106855913906081070",
    "license_key": license_key,
    "region": "US",
}

url = f"{base_url}?{urlencode(params)}"
request = Request(url, method="GET")

try:
    with urlopen(request, timeout=30) as response:
        status_code = response.status
        payload = json.loads(response.read().decode("utf-8"))
except HTTPError as error:
    print(f"HTTP-fel: {error.code}")
    raise
except URLError as error:
    print(f"Nätverksfel: {error.reason}")
    raise
except json.JSONDecodeError:
    raise RuntimeError("Tjänstens svar kunde inte tolkas som JSON")

print("HTTP-status:", status_code)
print("Nycklar på toppnivå:", list(payload.keys()))

Detta är en anpassning av den dokumenterade förfrågan, inte ett exempel som leverantören har testat separat för Python. Den beskriver inte heller alla möjliga svar från tjänsten. Eftersom nyckeln skickas i URL:en ska du inte skriva ut hela URL:en i loggar; den kan innehålla en hemlighet.

Så kontrollerar du JSON-svaret

I det publicerade Postman-svaret finns fältet status och det nästlade objektet tiktok.aweme_detail med information om videon och dess skapare. Det är ett exempel på formen hos ett enskilt svar, inte en garanti för att schemat förblir oförändrat. Du kan läsa det i svarexemplet för getVideoByID.

Kontrollera varje nivå när du läser nästlade fält:

def get_video_details(payload):
    tiktok = payload.get("tiktok")
    if not isinstance(tiktok, dict):
        return None

    details = tiktok.get("aweme_detail")
    if not isinstance(details, dict):
        return None

    return details

details = get_video_details(payload)

if details is None:
    print("Svaret saknar det förväntade objektet med videodata")
else:
    video_id = details.get("id")
    description = details.get("desc")
    author = details.get("author")

    print("ID:", video_id)
    print("Beskrivning:", description)
    print("Skapare:", author)

Fältnamnen kommer från det publicerade exemplet. Att kontrollera med .get() innebär inte att fälten är obligatoriska: det gör det möjligt att hantera svar som saknar de förväntade värdena. Om appens logik är beroende av ett visst fält bör du kontrollera att det finns i svar för ditt användningsfall och bestämma vad som ska hända om det saknas.

Det är användbart att skilja mellan tre kontroller:

1. Transport: Har ett HTTP-svar tagits emot och vilken status har det?
2. Format: Gick det att tolka svarskroppen som JSON?
3. Innehåll: Finns de data som appen behöver?

Att JSON kunde tolkas betyder inte att svaret innehåller det objekt du behöver. För felsökning kan du logga tekniska fel och resultat från kontrollerna, men maskera nycklarna.

Från en enda förfrågan till ett fungerande arbetsflöde

För en prototyp räcker det att skicka en förfrågan och skriva ut några värden. För återkommande hantering kan du dela upp arbetet i steg:

Förfrågan → kontroll → normalisering → deduplicering → lagring.

• Förfrågan. Hämta svaret via den dokumenterade rutten och spara den tekniska statusen separat.
• Kontroll. Säkerställ att svarskroppen kan tolkas som JSON och innehåller de data som behövs för den specifika uppgiften.
• Normalisering. För över de värden du behöver till din egen datamodell. Flytta inte hela den nästlade strukturen till databasen om appen bara behöver enskilda fält.
• Deduplicering. Välj en identifierare efter att du har kontrollerat att den finns och passar ditt användningsfall. Utgå inte från att den alltid är tillgänglig i alla svar.
• Lagring. Spara vid behov tidpunkten för förfrågan och det ursprungliga svaret separat från den normaliserade posten. Det gör det lättare att förstå vilka ändringar appen har gjort.

Detta är rekommendationer för hur appen kan utformas, inte funktioner som bör tillskrivas tjänsten. Om du skiljer det externa svaret från den interna datamodellen blir det också enklare att hantera ändringar: problem kan sökas upp i kontroll- eller normaliseringssteget i stället för i hela koden.

För återkommande förfrågningar bör du i förväg bestämma när data ska uppdateras och vilka fel som bör leda till ett nytt försök. Begränsa antalet försök: en oändlig loop löser inte en felaktig parameter eller ett autentiseringsproblem.

Cachning och region

I beskrivningen av rutten getVideoByID anger parametern cache_timeout cachetiden i sekunder: standardvärdet anges till 3 600 sekunder och 0 stänger av cachning. Parametern region beskrivs som en landskod, med US som exempel i dokumentationen. Kontrollera uppgifterna mot den aktuella Postman-dokumentationen för förfrågan innan du inför lösningen.

Att det finns en cacheinställning bekräftar inte i sig att ett visst svar är aktuellt. Om aktualitet är viktig bör du kontrollera resultaten från upprepade förfrågningar med data från ditt användningsfall och välja ett lämpligt beteende.

Vilka uppgifter kan du undersöka härnäst?

På produktsidan listas rutter för sökning efter videor och användare, hashtaggar, platser, musik och trender. Exemplen omfattar searchVideo, searchHashtag, getUserFeed och getTrendingFeed. Det är leverantörens publicerade översikt över rutter, inte en oberoende verifiering av var och en. Läs parametrarna och svarens struktur i dokumentationen för respektive rutt: de kan inte automatiskt hämtas från exemplet för getVideoByID.

jsonscraper rekommenderar att använda Postman-samlingen för att konfigurera nyckeln och köra förfrågningar. Det kan vara ett smidigt sätt att testa en enskild rutt innan du skriver en integration. Tjänsten listar också automatiseringsscenarier, men du bör kontrollera kompatibiliteten för det specifika arbetsflödet separat i din egen konfiguration. Om du exporterar samlingen eller delar den bör du försäkra dig om att ingen giltig nyckel finns kvar i den.

Det här bör du kontrollera innan du använder det i en app

Innan du lägger in förfrågan i en återkommande process bör du testa den med de videor och parametrar som projektet behöver:

• Går förfrågan igenom med en giltig nyckel och ett korrekt ID?
• Hur hanterar appen en felaktig eller saknad parameter?
• Vad händer om JSON-formateringen är korrekt men ett nödvändigt fält saknas?
• Hur hanteras HTTP-fel, nätverksavbrott och timeout?
• Vilka fält passar för identifiering och deduplicering i just ditt användningsfall?
• Hur ändras resultatet av en upprepad förfrågan vid olika värden på cache_timeout, om du använder parametern?

Anteckna datumet för kontrollen, parametrar utan hemligheter och ett anonymiserat exempel på svaret. En lyckad förfrågan bekräftar bara att ett specifikt scenario fungerar under specifika förhållanden; den bevisar inte att alla rutter och svar är stabila.

Börja med ett reproducerbart scenario

Testa getVideoByID med den video du behöver, granska den faktiska JSON-datan och skriv en hanterare som tar hänsyn till saknade fält och fel. Utöka sedan processen med normalisering, deduplicering och lagring om det behövs.

jsonscrapers dokumentation ger en utgångspunkt med basadressen och en översikt över rutterna. I produktionskod behöver du ändå kontrollera det faktiska svaret, skydda nyckeln och hantera situationer där data avviker från den förväntade strukturen.