Innan du börjar
Du behöver:- behörighet att hantera integrationer och åtkomstnycklar i Living Security
- en serverbaserad avsändare som kan göra HTTPS-anrop av typen
POST - den Living Security-region som din organisation tillhör
- ett stabilt källnamn och minst ett strömnamn
1. Registrera källan och strömmarna
1
Öppna Custom Push Source
Gå till Inställningar → Integrationer → Katalog, leta upp Custom Push Source och välj Lägg till.
2
Namnge källan
Ange källans routningsnyckel och en valfri beskrivning. Använd till exempel
custom-phishing-sim i stället för ett visningsnamn med mellanslag.3
Lägg till strömmar
Lägg till varje ström som avsändaren ska använda. Paret av källa och ström måste finnas innan den första överföringen; ett okänt par returnerar
404 Not Found.4
Spara källan
Öppna källan efter att den skapats under Inställningar → Integrationer → ansluten. Vyn Push via API visar slutpunktsmönstret och senaste körningar.
2. Skapa en nyckel för push-inmatning
Gå till Inställningar → Access Keys, välj Create Access Key och välj scopet Push Ingest. Kopiera det genererade värdet direkt; det visas bara en gång. Nyckeln är kopplad till en enda Living Security-organisation. Push-anropet behöver ingen organisationshuvud. Se API Access Keys för rotation och återkallelse.3. Välj den regionala slutpunkten
Använd värdnamnet för din Living Security-organisation:
Lägg till
/push-ingest/{integrationKey}/{streamName}. Sökvägen är skiftlägeskänslig och måste exakt motsvara den registrerade källan och strömmen.
string
obligatorisk
Det registrerade källnamnet. Använd 1–64 gemener, siffror eller bindestreck, med början på en bokstav eller siffra.
string
obligatorisk
Det registrerade strömnamnet. Samma regler gäller, och understreck är också tillåtna.
string
obligatorisk
Skicka åtkomstnyckeln för push-inmatning som
Bearer <access-key>.string
Använd
application/json för JSON eller text/csv för CSV. Servern kan också identifiera en JSON-array när den här rubriken utelämnas.string
Valfritt organisations-UUID. Åtkomstnyckeln avgör redan organisationen. Om du skickar den här rubriken måste den överensstämma med nyckelns organisation; den kan inte användas för att välja en annan organisation.
Förfrågans brödtext
Skicka en JSON-array på toppnivå som inte är tom och som innehåller objekt, eller bytes från en CSV-fil med en rubrikrad. Det finns inget namngivet JSON-omslagsfält. Varje batch kan innehålla upp till 10 000 poster och 10 MB.4. Skicka en JSON-batch
Skicka en JSON-array som inte är tom och vars element är objekt.Content-Type: application/json rekommenderas och krävs av många sändande produkter, även om Living Security kan identifiera en array i brödtexten utan den.
202 Accepted. Felfliken visar ett 400 Bad Request när JSON-brödtexten är felformaterad:
400: korrigera JSON eller skicka CSV med Content-Type: text/csv och försök sedan igen.
string
obligatorisk
Körnings-ID för den här godkända batchen. Spara det för att kontrollera bearbetningsstatus.
number
obligatorisk
Antalet poster som har godkänts och lagrats.
string
obligatorisk
Det källnamn som användes för den här överföringen.
string
obligatorisk
Det strömnamn som användes för den här överföringen.
Skicka CSV i stället
AngeContent-Type: text/csv och skicka filens bytes, som visas i förfrågningsexemplet CSV file ovan. Den första raden anger fältnamnen.
Booleansk text blir ett booleskt värde och vanlig numerisk text blir ett tal. Värden med inledande nollor, osäkert stora heltal, datum och annan text förblir strängar. Tomma celler utelämnar fältet. Felformaterade rader, obalanserade citattecken och UTF-16-filer avvisas.
Begränsningar för förfrågningar och nya försök
Dela upp större exporter i batchar som uppfyller båda begränsningarna. Vänta på varje svar och spara det returnerade
runId i avsändarens loggar.
Den normala gränsen för autentiserade organisationer returnerar
503, inte 429, så att avsändare av webhooks behandlar den som möjlig att försöka igen. Ett 503 returneras innan batchen lagras; att skicka samma batch igen efter det angivna intervallet skapar inte en dubblett av en godkänd körning.
Verifiera dataflödet
Öppna Custom Push Source och granska Push History. Bekräfta strömmen, antalet poster, nyckelattribueringen och bearbetningsstatusen. Data med en underhållen tolk kan sedan bli personer och normaliserad aktivitet. Data utan tolk förblir lagrade men genererar ingen aktivitet.Använd exakta fältnamn och nyttolaststruktur från den leverantörsspecifika guiden när
en sådan finns. Ett lyckat
202 bevisar leverans, inte att ett godtyckligt schema
mappas till Living Security-aktivitet.Checklista för felsökning
- Kopiera slutpunkten från rätt källa och ersätt platshållaren för strömmen.
- Skicka åtkomstnyckeln som
Authorization: Bearer …;x-api-keyaccepteras inte. - Bekräfta att brödtexten är en JSON-array på toppnivå, inte ett enskilt objekt eller ett omslag runt posterna.
- Bekräfta stavningen av källa och ström, inklusive bindestreck, understreck och skiftläge.
- Granska Push History innan du skickar om en batch vars svar gick förlorat.
- När du kontaktar Living Securitys support, ange organisation, källa, ström, förfrågningstid,
runIdnär det finns och svarsstatus. Ta inte med åtkomstnyckeln eller händelsenyttolasten.
Relaterat
Zscaler ZIA Cloud NSS
Konfigurera ett Zscaler-webbloggflöde som stöds, med exakt källa, ström, rubriker och JSON-struktur.
API Access Keys
Skapa, rotera och återkalla autentiseringsuppgifter med begränsat scope.
Signal Data Sources
Läs om hur tolkad integrationsaktivitet stöder Signaler.

