TikTok Scraper API: Slik henter du videodata i JSON med jsonscraper

Hvis en app trenger informasjon om en bestemt TikTok-video, er det enklest å begynne med én forespørsel og undersøke hvilke data den returnerer. Deretter kan svaret valideres og klargjøres for lagring eller analyse.

På siden for TikTok Scraper API fra jsonscraper er endepunkter for videoer, brukere, søk, emneknagger, musikk og andre datatyper listet opp. Nedenfor går vi gjennom den dokumenterte forespørselen getVideoByID og hvordan svaret kan behandles på en sikker måte. Eksemplene bygger på leverandørens materiale; test dem med en aktiv nøkkel og oppdatert dokumentasjon før bruk.

Første forespørsel: Hent informasjon om en video

I Postman-dokumentasjonen for getVideoByID er GET-metoden og parameteren video_id angitt. Eksemplet viser også region og cache_timeout. Basisadressen som er publisert på tjenestesiden, er https://tiktok.evelode.com.

Eksempel på en forespørsel med cURL:

export JSONSCRAPER_LICENSE_KEY="din_nøkkel"

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

ID-en i eksemplet er hentet fra den publiserte forespørselen. Bytt den ut med ID-en til videoen du vil undersøke. Oppbevar nøkkelen i en miljøvariabel eller en hemmelighetsbehandler: ikke legg den i et offentlig repositorium, JavaScript på klientsiden eller logger.

Postman beskriver region som en regionskode og oppgir US som standardverdi. For cache_timeout angir dokumentasjonen et standard hurtigbufferintervall på 3600 sekunder; verdien 0 slår av hurtigbufring. Hvis parameteren er relevant for bruksområdet ditt, kan du sende den eksplisitt:

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"

Dette er en tilpasning av parameterne som er publisert for endepunktet, ikke en garanti for at alle svar har samme struktur eller at det passer å slå av hurtigbufring i alle tilfeller. Kontroller autentisering og parametere mot den gjeldende samlingen før implementering: Postman kan sende nøkkelen gjennom en konfigurert API Key, mens cURL-eksemplet ovenfor viser den som en URL-parameter.

Samme forespørsel i Python

Nedenfor finner du en variant som bruker Pythons standardbibliotek. Den setter sammen en GET-forespørsel, sender parameterne og håndterer nettverksfeil, HTTP-feil og ugyldig 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("Angi miljøvariabelen 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-feil: {error.code}")
    raise
except URLError as error:
    print(f"Nettverksfeil: {error.reason}")
    raise
except json.JSONDecodeError:
    raise RuntimeError("Kunne ikke tolke tjenestesvaret som JSON")

print("HTTP-status:", status_code)
print("Nøkler på øverste nivå:", list(payload.keys()))

Dette er en tilpasning av den dokumenterte forespørselen, ikke et eksempel leverandøren har testet separat for Python. Det dekker heller ikke alle mulige svar fra tjenesten. Siden nøkkelen sendes i URL-en, må du unngå å skrive ut hele URL-en i logger: den kan inneholde en hemmelighet.

Slik validerer du JSON-svaret

I det publiserte Postman-svaret finnes feltet status og det nestede objektet tiktok.aweme_detail med video- og forfatterdata. Dette er et eksempel på formen til ett svar, ikke en garanti for at skjemaet forblir uendret. Du kan se nærmere på det i svareksemplet for getVideoByID.

Kontroller hvert nivå når du leser nestede felt:

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 inneholder ikke det forventede objektet med videodata")
else:
    video_id = details.get("id")
    description = details.get("desc")
    author = details.get("author")

    print("ID:", video_id)
    print("Beskrivelse:", description)
    print("Forfatter:", author)

Feltnavnene er hentet fra det publiserte eksemplet. Bruk av .get() betyr ikke at feltene er obligatoriske; metoden gjør det mulig å håndtere svar der forventede verdier mangler. Hvis appens logikk avhenger av et bestemt felt, bør du kontrollere at det finnes i svar for ditt bruksområde og legge til håndtering for tilfeller der det mangler.

Det er nyttig å skille mellom tre kontroller:

1. Transport: Ble et HTTP-svar mottatt, og hva er statusen?
2. Format: Kunne svarinnholdet tolkes som JSON?
3. Innhold: Finnes dataene appen trenger?

At JSON kan tolkes, betyr ikke nødvendigvis at svaret inneholder det nødvendige objektet. Når du feilsøker, bør du logge tekniske feil og resultatene av kontrollene, men maskere nøklene.

Fra én forespørsel til en arbeidsflyt

For en prototype er det nok å sende en forespørsel og skrive ut noen verdier. For regelmessig behandling bør du dele arbeidet inn i trinn:

Forespørsel → kontroll → normalisering → deduplisering → lagring.

• Forespørsel. Hent et svar fra det dokumenterte endepunktet, og lagre den tekniske statusen separat.
• Kontroll. Kontroller at innholdet kan tolkes som JSON og inneholder dataene som trengs for den aktuelle oppgaven.
• Normalisering. Flytt de nødvendige verdiene over i din egen datamodell. Ikke kopier hele den nestede strukturen til databasen hvis appen bare trenger noen få felt.
• Deduplisering. Velg en identifikator etter at du har kontrollert at den finnes og passer til oppgaven. Ikke anta at den alltid er tilgjengelig i alle svar.
• Lagring. Ved behov kan du lagre tidspunktet for forespørselen og originalsvaret separat fra den normaliserte oppføringen. Da blir det enklere å forstå hvilke endringer appen har gjort.

Dette er anbefalinger for utformingen av appen, ikke funksjoner som bør tilskrives tjenesten. Ved å skille det eksterne svaret fra den interne datamodellen blir det også enklere å håndtere endringer: problemer kan spores til kontroll- eller normaliseringstrinnet i stedet for gjennom hele koden.

For gjentatte forespørsler bør du på forhånd bestemme når dataene skal oppdateres, og hvilke feil det er verdt å prøve på nytt. Begrens antall nye forsøk: en uendelig løkke løser verken en ugyldig parameter eller et autentiseringsproblem.

Hurtigbufring og region

I beskrivelsen av endepunktet getVideoByID angir parameteren cache_timeout hurtigbufferens varighet i sekunder: standardverdien er oppgitt til 3600 sekunder, og 0 slår av hurtigbufring. Parameteren region beskrives som en landskode; dokumentasjonen viser US som eksempel. Kontroller disse opplysningene mot den oppdaterte dokumentasjonen for forespørselen i Postman før implementering.

At det finnes en hurtigbufferinnstilling, bekrefter ikke at et bestemt svar er ferskt. Hvis ferskhet er viktig, bør du teste resultatene av gjentatte forespørsler med data fra ditt eget bruksområde og velge en passende løsning.

Hvilke oppgaver kan du utforske videre?

Produktsiden lister opp endepunkter for søk etter videoer og brukere, emneknagger, steder, musikk og trender. Blant eksemplene er searchVideo, searchHashtag, getUserFeed og getTrendingFeed. Dette er leverandørens publiserte oversikt over endepunkter, ikke en uavhengig kontroll av hvert enkelt. Undersøk parametere og svarformat i dokumentasjonen for det aktuelle endepunktet: de kan ikke uten videre overføres fra eksemplet for getVideoByID.

jsonscraper foreslår å bruke Postman-samlingen til å konfigurere nøkkelen og sende forespørsler. Det kan være en praktisk måte å teste et enkelt endepunkt på før du skriver en integrasjon. Tjenesten lister også opp automatiseringsscenarioer, men kontroller kompatibiliteten til den konkrete arbeidsflyten separat i ditt eget oppsett. Når du eksporterer samlingen eller deler den, må du kontrollere at en aktiv nøkkel ikke ligger igjen i den.

Dette bør du kontrollere før bruk i appen

Før du tar forespørselen inn i en regelmessig prosess, bør du teste den med videoene og parameterne prosjektet trenger:

• Fungerer forespørselen med en aktiv nøkkel og en gyldig ID?
• Hvordan håndterer appen en ugyldig eller manglende parameter?
• Hva skjer hvis JSON er gyldig, men det nødvendige feltet mangler?
• Hvordan håndteres HTTP-feil, nettverksbrudd og tidsavbrudd?
• Hvilke felt egner seg til identifisering og deduplisering i akkurat ditt bruksområde?
• Hvordan endres resultatet av en ny forespørsel med ulike verdier for cache_timeout, hvis du bruker denne parameteren?

Noter datoen for kontrollen, parametere uten hemmeligheter og et anonymisert svar-eksempel. Én vellykket forespørsel bekrefter bare at det konkrete scenarioet fungerer under de aktuelle forholdene; den beviser ikke at alle endepunkter og svar er stabile.

Begynn med ett scenario som kan gjentas

Test getVideoByID med den aktuelle videoen, undersøk den faktiske JSON-en og skriv en behandler som tar høyde for manglende felt og feil. Utvid deretter prosessen med normalisering, deduplisering og lagring hvis det er nødvendig.

Dokumentasjonen fra jsonscraper gir et utgangspunkt med basisadressen og en oversikt over endepunktene. I produksjonskode må du likevel kontrollere det konkrete svaret, beskytte nøkkelen og ta høyde for at dataene kan avvike fra forventet struktur.