Før du begynner
Du trenger:- tillatelse til å administrere integrasjoner og tilgangsnøkler i Living Security
- en avsender på serversiden som kan sende HTTPS
POST-forespørsler - Living Security-regionen for organisasjonen din
- et stabilt kildenavn og minst ett strømnavn
1. Registrer kilden og strømmene
1
Åpne Custom Push Source
Gå til Innstillinger → Integrasjoner → Catalog, finn Custom Push Source, og velg Legg til.
2
Gi kilden et navn
Angi rutingnøkkelen for kilden og en valgfri beskrivelse. Bruk for eksempel
custom-phishing-sim i stedet for et visningsnavn med mellomrom.3
Legg til strømmer
Legg til hver strøm som avsenderen skal bruke. Paret av kilde og strøm må finnes før den første pushen; et ukjent par returnerer
404 Not Found.4
Lagre kilden
Etter opprettelsen åpner du kilden under Innstillinger → Integrasjoner → tilkoblet. Visningen Push via API viser endepunktmønsteret og nylige kjøringer.
2. Opprett en push-ingest-nøkkel
Gå til Innstillinger → Access Keys, velg Create Access Key, og velg omfanget Push Ingest. Kopier den genererte verdien umiddelbart; den vises bare én gang. Nøkkelen er knyttet til én Living Security-organisasjon. Push-forespørselen trenger ingen organisasjonsheader. Se API Access Keys for rotasjon og tilbakekalling.3. Velg det regionale endepunktet
Bruk vertsnavnet for Living Security-organisasjonen:
Legg til
/push-ingest/{integrationKey}/{streamName}. Stien skiller mellom store og små bokstaver og må samsvare nøyaktig med den registrerte kilden og strømmen.
string
påkrevd
Det registrerte kildenavnet. Bruk 1–64 små bokstaver, sifre eller bindestreker, og begynn med en bokstav eller et siffer.
string
påkrevd
Det registrerte strømnavnet. De samme reglene gjelder, og understreker er også tillatt.
string
påkrevd
Send push-ingest-tilgangsnøkkelen som
Bearer <access-key>.string
Bruk
application/json for JSON eller text/csv for CSV. Serveren kan også gjenkjenne et JSON-array når denne headeren utelates.string
Valgfri organisasjons-UUID. Tilgangsnøkkelen bestemmer allerede organisasjonen. Hvis du sender denne headeren, må den samsvare med nøkkelens organisasjon; den kan ikke brukes til å velge en annen organisasjon.
Forespørselsinnhold
Send et ikke-tomt JSON-array av objekter på øverste nivå, eller CSV-filbyte med en overskriftsrad. Det finnes ikke noe navngitt JSON-omslagsfelt. Hver batch kan inneholde opptil 10 000 poster og 10 MB.4. Send en JSON-batch
Send et ikke-tomt JSON-array der elementene er objekter.Content-Type: application/json anbefales og kreves av mange avsenderprodukter, selv om Living Security kan gjenkjenne et array-innhold uten den.
202 Accepted. Feilfanen viser en 400 Bad Request når JSON-innholdet er ugyldig utformet:
400 må du rette JSON-en eller sende CSV med Content-Type: text/csv, og deretter prøve på nytt.
string
påkrevd
Kjøre-ID-en for denne aksepterte batchen. Ta vare på den for å kunne sjekke behandlingsstatus.
number
påkrevd
Antall poster som er akseptert og lagret.
string
påkrevd
Kildenavnet som ble brukt for denne pushen.
string
påkrevd
Strømnavnet som ble brukt for denne pushen.
Send CSV i stedet
AngiContent-Type: text/csv og send filbyte, slik det vises i forespørselseksempelet CSV file ovenfor. Den første raden angir feltnavnene.
Boolsk tekst blir til en boolsk verdi, og vanlig numerisk tekst blir til et tall. Verdier med innledende null, usikre store heltall, datoer og annen tekst forblir strenger. Tomme celler utelater feltet. Feilformede rader, ubalanserte anførselstegn og UTF-16-filer avvises.
Forespørselsgrenser og nye forsøk
Del opp større eksporter i batcher som oppfyller begge grensene. Vent på hvert svar, og ta vare på den returnerte
runId i avsenderens logger.
Den normale grensen for autentisert organisasjon returnerer
503, ikke 429, slik at webhook-avsendere behandler den som noe som kan prøves på nytt. En 503 returneres før batchen lagres; å sende den samme batchen på nytt etter det oppgitte intervallet gir ikke en duplisert akseptert kjøring.
Verifiser datastrømmen
Åpne Custom Push Source og se gjennom Push History. Bekreft strøm, antall poster, nøkkelattribusjon og behandlingsstatus. Data med en vedlikeholdt tolker kan deretter bli til personer og normalisert aktivitet. Data uten tolker forblir lagret, men gir ikke aktivitet.Bruk de nøyaktige feltnavnene og nyttelaststrukturen fra den leverandørspesifikke veiledningen
når det finnes en. Et vellykket
202 beviser levering, ikke at et vilkårlig skjema
tilordnes Living Security-aktivitet.Sjekkliste for feilsøking
- Kopier endepunktet fra riktig kilde og erstatt plassholderen for strømmen.
- Send tilgangsnøkkelen som
Authorization: Bearer …;x-api-keygodtas ikke. - Bekreft at innholdet er et JSON-array på øverste nivå, ikke et enkeltobjekt eller en omslagsstruktur rundt postene.
- Bekreft stavemåten for kilde og strøm, inkludert bindestreker, understreker og store/små bokstaver.
- Se gjennom Push History før du sender på nytt en batch der svaret gikk tapt.
- Når du kontakter Living Security Support, oppgi organisasjon, kilde, strøm, tidspunkt for forespørselen,
runIdnår den er tilgjengelig, og responsstatus. Ikke ta med tilgangsnøkkelen eller hendelsesnyttelasten.
Relatert
Zscaler ZIA Cloud NSS
Konfigurer en støttet Zscaler-nettlogg-feed med nøyaktig kilde, strøm, headere og JSON-struktur.
API Access Keys
Opprett, roter og tilbakekall legitimasjon med begrenset omfang.
Signal Data Sources
Lær hvordan tolket integrasjonsaktivitet understøtter Signaler.

