Skip to main content
Maak een serviceaccount en een API-sleutel aan in de Developer Hub en doe vervolgens uw eerste aanvraag. Deze quickstart maakt gebruik van authenticatie met een API-sleutel; u hebt geen OAuth-client nodig. Raadpleeg Authenticatie als uw integratie kortlevende OAuth-toegangstokens vereist.

Vereisten

  • Beheerderstoegang tot het Living Security Dashboard.
  • De Developer Hub is zichtbaar onder Instellingen → Integraties & Developers → Developer Hub.

Inloggegevens aanmaken

1

Een serviceaccount aanmaken

Open in de Developer Hub het tabblad Service accounts en maak een account aan. Geef het een beschrijvende naam (bijvoorbeeld reporting-pipeline) en verleen de machtigingen die de bijbehorende sleutels mogen gebruiken — voor deze handleiding is organization:read voldoende.De machtigingen van het account vormen het maximum voor elke sleutel die eronder wordt aangemaakt: een sleutel kan nooit meer dan wat het serviceaccount toestaat.
2

Een API-sleutel aanmaken

Open de detailpagina van het serviceaccount en maak een sleutel aan. Kies de machtigingen die deze specifieke sleutel nodig heeft (een subset van die van het account) en een vervaldatum — 30, 90 of 365 dagen, of een aangepaste periode. Een vervaldatum is verplicht.Het geheim van de sleutel begint met lsk_live_ en wordt één keer getoond. Kopieer het direct naar een secretmanager; het kan later niet meer worden opgehaald.
Commit geheimen van API-sleutels nooit naar versiebeheer en sluit ze niet in in code aan de clientzijde. Iedereen die over het geheim beschikt, kan handelen met de machtigingen van de sleutel.
3

Uw regio kiezen

Roep de regionale /v1-host aan die overeenkomt met de dataresidentie van de organisatie. Sleutels authenticeren alleen op die host.Raadpleeg Regio’s als u niet zeker weet welke host u moet gebruiken. Een geldige sleutel die naar de andere regio wordt verzonden, mislukt met unauthorized. Gebruik de regiodropdown bij het onderstaande voorbeeld om van host te wisselen.
4

Uw eerste aanvraag doen

Laad LIVING_SECURITY_API_KEY vanuit uw secretmanager in de omgeving van het proces dat de aanvraag doet. De onderstaande voorbeelden lezen het uit zonder een geheim in de broncode op te nemen. Installeer voor Python eerst requests.Roep de API aan met het geheim in het wachtwoord- of gebruikersnaamveld van HTTP Basic-authenticatie — beide werken, zodat clients die vereisen dat beide velden zijn ingevuld (zoals de Web-connector van Power BI) in het andere veld een plaatshouder zoals apikey kunnen plaatsen.
Een geslaagde respons retourneert uw organisatie:
Response
Als u deze respons ontvangt, werken uw inloggegevens. De aanvraag verschijnt binnen enkele ogenblikken ook op het tabblad Request logs van de Developer Hub.
Bearer-authenticatie met hetzelfde geheim (Authorization: Bearer lsk_live_...) werkt ook. Basic-authenticatie bestaat zodat tools die alleen gebruikersnaam/wachtwoord ondersteunen — zoals de Web-connector van Power BI — verbinding kunnen maken.

Hoe authenticatie werkt

  • De inloggegevens bepalen de organisatie. /v1-aanvragen bevatten geen tenantselector: geen organisatiepadsegment en geen organisatieheader. Het verzenden van een x-organization-id-header wordt geweigerd met invalid_request. De host moet nog steeds overeenkomen met de regio van die organisatie. Zie Regio’s.
  • Machtigingen worden per bewerking gecontroleerd. Elke /v1-bewerking vereist een benoemde machtiging (GET /v1/organization vereist bijvoorbeeld organization:read). Een sleutel zonder de machtiging krijgt een 403 met code insufficient_permission.
  • Sleutels verlopen en kunnen zonder downtime worden geroteerd. Zie API-sleutels voor rotatie met een overlapperiode.

Foutresponsen lezen

Elke /v1-fout is application/problem+json (RFC 9457) met een stabiele machinecode. Een aanvraag met ontbrekende of onbekende inloggegevens retourneert bijvoorbeeld:
401 Unauthorized
Vertak op basis van code, nooit op basis van detail. Volg doc_url voor de oplossingsstappen en vermeld request_id wanneer u contact opneemt met support — het komt overeen met de Request-Id-responsheader en de aanvraaglogboeken van de Developer Hub. De volledige set codes vindt u in de foutreferentie.

Contractversies

Elke respons geeft de contractversie waarmee de aanvraag is afgehandeld terug in de Living-Security-Version-header, naast een Request-Id-header voor correlatie. U kunt een aanvraag vastzetten op een gepubliceerde contractversie op datum:
De versie wordt in deze volgorde bepaald: de aanvraagheader indien aanwezig, anders de vastgezette standaardversie van het serviceaccount, anders de nieuwste gepubliceerde versie. Het aanvragen van een versie die niet is gepubliceerd (of de einddatum heeft overschreden) retourneert een 400 met code unsupported_version. Gepubliceerde versies en hun wijzigingen staan in de API-changelog.

Problemen met uw eerste aanvraag oplossen

Volg voor andere fouten de doc_url van de respons. Bewaar de Request-Id voor support; neem nooit de Authorization-header of uw API-sleutel op in een ticket.

Volgende stappen

Regio's

Kies de /v1-host voor de VS of de EU voor de organisatie.

Paginering

Doorloop lijsten met page_token en de lijstenvelop.

Rate limits

Begrijp aanvraagbudgetten en verwerk 429-responsen.

Foutreferentie

Elke foutcode, de bijbehorende HTTP-status en hoe u deze oplost.

Developer Hub

Beheer serviceaccounts, API-sleutels en aanvraaglogboeken.