ThoughtSpot: authenticatie REST API v2 en foutmelding 401 oplossen

Samenvatting

ThoughtSpot REST API v2 gebruikt bearer-tokens; een 401 ontstaat vaak door een verlopen token of verkeerde Org.

ThoughtSpot REST API v2: wat er gebeurt

ThoughtSpot geeft tokens uit via `/api/rest/2.0/auth/token/full`. Elke token hoort bij één gebruiker en één Org, de term die ThoughtSpot gebruikt voor een tenant, en blijft standaard 300 seconden geldig. Bij iedere API-aanroep stuur je de token mee in de header `Authorization: Bearer <token>`.

Een 401 wijst meestal op een ontbrekende of verkeerd opgebouwde header, een verlopen token, een token voor een andere Org of onvoldoende toegang tot het opgevraagde object. ThoughtSpot controleerde deze uitleg tegen REST API SDK 2.29.1 en de ThoughtSpot Cloud 26.10.0.cl-documentatie.

ThoughtSpot REST API v2: waarom dit belangrijk is

De API ondersteunt taken zoals gebruikers aanmaken, content importeren en exporteren via TML, rechten instellen, planningen beheren, webhooks gebruiken en Spotter-conversaties aanspreken. Daarmee ligt de authenticatiekeuze direct aan de basis van backend-automatisering, bijvoorbeeld bij registratie, deployment vanuit CI of vragen vanuit een applicatie.

De foutanalyse begint met `/api/rest/2.0/auth/session/user`. Geeft die aanroep ook 401 terug, dan zit het probleem bij de token of de Org. Verschijnt wel een gebruiker, controleer dan de Org en de toegang tot het object. Let daarnaast op `Accept: application/json`, `Content-Type: application/json` en een `User-Agent`; een verkeerde Content-Type geeft 415.

ThoughtSpot REST API v2: concrete takeaway

Controleer eerst de sessiegebruiker voordat je rechten of objecten onderzoekt. Vraag voor lange taken een nieuwe token aan of gebruik `validity_time_in_sec`, en leg in je integratie vast dat elke aanvraag de juiste bearer-header, User-Agent en JSON-headers bevat.