Egyéni Push forrás API

curl --request POST \
  'https://api.us-east-1.livingsecurity.ai/api/v1/push-ingest/custom-phishing-sim/events' \
  --header 'Authorization: Bearer <access-key>' \
  --header 'Content-Type: application/json' \
  --data '[
    {
      "email": "person@example.com",
      "event_at": "2026-09-21T14:30:00Z",
      "action": "reported"
    }
  ]'

curl --request POST \
  'https://api.us-east-1.livingsecurity.ai/api/v1/push-ingest/custom-phishing-sim/events' \
  --header 'Authorization: Bearer <access-key>' \
  --header 'Content-Type: text/csv' \
  --data-binary '@events.csv'

{
  "runId": "01a0c45f-ae40-7e5f-8a9b-0c1d2e3f4a5b",
  "recordsAccepted": 1,
  "integrationKey": "custom-phishing-sim",
  "streamName": "events"
}

{
  "statusCode": 400,
  "timestamp": "2026-09-22T14:30:00.000Z",
  "path": "/api/v1/push-ingest/custom-phishing-sim/events",
  "message": "Request body is not valid JSON. Send a JSON array of objects, or set Content-Type: text/csv to push a CSV.",
  "error": "Bad Request"
}

curl --request POST \
  'https://api.us-east-1.livingsecurity.ai/api/v1/push-ingest/custom-phishing-sim/events' \
  --header 'Authorization: Bearer <access-key>' \
  --header 'Content-Type: application/json' \
  --data '[
    {
      "email": "person@example.com",
      "event_at": "2026-09-21T14:30:00Z",
      "action": "reported"
    }
  ]'

curl --request POST \
  'https://api.us-east-1.livingsecurity.ai/api/v1/push-ingest/custom-phishing-sim/events' \
  --header 'Authorization: Bearer <access-key>' \
  --header 'Content-Type: text/csv' \
  --data-binary '@events.csv'

{
  "runId": "01a0c45f-ae40-7e5f-8a9b-0c1d2e3f4a5b",
  "recordsAccepted": 1,
  "integrationKey": "custom-phishing-sim",
  "streamName": "events"
}

{
  "statusCode": 400,
  "timestamp": "2026-09-22T14:30:00.000Z",
  "path": "/api/v1/push-ingest/custom-phishing-sim/events",
  "message": "Request body is not valid JSON. Send a JSON array of objects, or set Content-Type: text/csv to push a CSV.",
  "error": "Bad Request"
}

Használjon Custom Push Source forrást, ha egy rendszer a Living Security felé küldi a rekordokat, ahelyett, hogy egy katalógusbeli összekötő kérdezné le azokat. A küldő JSON-tömböket vagy CSV-fájlokat küldhet egy regionális HTTPS-végpontra.

Előkészületek

A következőkre van szüksége:

jogosultság az integrációk és a hozzáférési kulcsok kezelésére a Living Security rendszerben
szerveroldali küldő, amely HTTPS POST kéréseket tud küldeni
a szervezete Living Security régiója
egy állandó forrásnév és legalább egy adatfolyamnév

A forrásnevek és az adatfolyamnevek állandó útválasztási kulcsok. A forrásnév 1–64 karakter hosszú lehet, kisbetűkből, számjegyekből vagy kötőjelekből állhat. Az adatfolyamnevekben az aláhúzásjel is megengedett. Mindkettőnek betűvel vagy számjeggyel kell kezdődnie.

Kezelje az API-hozzáférési kulcsot titkos adatként. Ne helyezze böngészőkódba, ne commitolja verziókezelőbe, és ne küldje el támogatási jegyben.

1. A forrás és az adatfolyamok regisztrálása

A Custom Push Source megnyitása

Lépjen a Beállítások → Integrációk → Katalógus területre, keresse meg a Custom Push Source elemet, és válassza a Hozzáad lehetőséget.

A forrás elnevezése

Adja meg a forrás útválasztási kulcsát és egy opcionális leírást. Használjon például custom-phishing-sim értéket a szóközöket tartalmazó megjelenített név helyett.

Adatfolyamok hozzáadása

Adja hozzá az összes adatfolyamot, amelyet a küldő használni fog. A forrás–adatfolyam párnak léteznie kell az első küldés előtt; ismeretlen pár esetén a válasz 404 Not Found lesz.

A forrás mentése

A létrehozás után nyissa meg a forrást a Beállítások → Integrációk → Csatlakoztatva területen. A Push via API nézet megjeleníti a végpontmintát és a legutóbbi futásokat.

2. Push-ingest kulcs létrehozása

Lépjen a Beállítások → Access Keys területre, válassza a Create Access Key lehetőséget, majd válassza a Push Ingest hatókört. Az előállított értéket azonnal másolja ki, mert csak egyszer jelenik meg. A kulcs egyetlen Living Security szervezethez van kötve. A push kérésnek nincs szüksége szervezetfejlécre. A forgatással és visszavonással kapcsolatban lásd az API-hozzáférési kulcsok oldalt.

3. A regionális végpont kiválasztása

Használja a Living Security szervezetének megfelelő állomásnevet:

Régió	Alap URL
Egyesült Államok	`https://api.us-east-1.livingsecurity.ai/api/v1`
Európai Unió	`https://api.eu-west-1.livingsecurity.ai/api/v1`

Fűzze hozzá a következőt: /push-ingest/{integrationKey}/{streamName}. Az útvonal megkülönbözteti a kis- és nagybetűket, és pontosan egyeznie kell a regisztrált forrással és adatfolyammal.

string

kötelező

A regisztrált forrásnév. 1–64 kisbetűt, számjegyet vagy kötőjelet használjon, betűvel vagy számjeggyel kezdve.

string

kötelező

A regisztrált adatfolyamnév. Ugyanezek a szabályok érvényesek, az aláhúzásjel is megengedett.

string

kötelező

A push-ingest hozzáférési kulcsot Bearer <access-key> formában küldje el.

string

JSON esetén application/json, CSV esetén text/csv értéket használjon. A szerver a JSON-tömböt a fejléc hiányában is felismerheti.

string

Opcionális szervezeti UUID. A hozzáférési kulcs már meghatározza a szervezetet. Ha elküldi ezt a fejlécet, egyeznie kell a kulcs szervezetével; nem választható vele másik szervezet.

Kérés törzse

Küldjön egy legfelső szintű, nem üres JSON-objektumtömböt vagy fejlécsort tartalmazó CSV-fájl bájtjait. Nincs elnevezett JSON-burkolómező. Egy köteg legfeljebb 10 000 rekordot és 10 MB-ot tartalmazhat.

4. JSON-köteg küldése

Küldjön egy nem üres JSON-tömböt, amelynek elemei objektumok. A Content-Type: application/json használata ajánlott, és számos küldő termék megköveteli, annak ellenére, hogy a Living Security a tömb törzset enélkül is felismeri.

curl --request POST \
  'https://api.us-east-1.livingsecurity.ai/api/v1/push-ingest/custom-phishing-sim/events' \
  --header 'Authorization: Bearer <access-key>' \
  --header 'Content-Type: application/json' \
  --data '[
    {
      "email": "person@example.com",
      "event_at": "2026-09-21T14:30:00Z",
      "action": "reported"
    }
  ]'

curl --request POST \
  'https://api.us-east-1.livingsecurity.ai/api/v1/push-ingest/custom-phishing-sim/events' \
  --header 'Authorization: Bearer <access-key>' \
  --header 'Content-Type: text/csv' \
  --data-binary '@events.csv'

A sikeres kérés 202 Accepted választ ad vissza. A hiba lap 400 Bad Request választ mutat, ha a JSON-törzs hibás formátumú:

{
  "runId": "01a0c45f-ae40-7e5f-8a9b-0c1d2e3f4a5b",
  "recordsAccepted": 1,
  "integrationKey": "custom-phishing-sim",
  "streamName": "events"
}

{
  "statusCode": 400,
  "timestamp": "2026-09-22T14:30:00.000Z",
  "path": "/api/v1/push-ingest/custom-phishing-sim/events",
  "message": "Request body is not valid JSON. Send a JSON array of objects, or set Content-Type: text/csv to push a CSV.",
  "error": "Bad Request"
}

Az elfogadás azt jelenti, hogy a köteg aszinkron feldolgozásra tárolásra került. Nem jelenti azt, hogy minden rekord már tevékenységgé lett értelmezve. A 400 példa esetén javítsa ki a JSON-t, vagy küldjön CSV-t Content-Type: text/csv használatával, majd próbálja újra.

string

kötelező

Az elfogadott köteg futtatási azonosítója. Őrizze meg a feldolgozási állapot ellenőrzéséhez.

number

kötelező

Az elfogadott és tárolt rekordok száma.

string

kötelező

Az ehhez a küldéshez használt forrásnév.

string

kötelező

Az ehhez a küldéshez használt adatfolyamnév.

CSV küldése helyette

Állítsa be a következőt: Content-Type: text/csv, és küldje el a fájl bájtjait, ahogyan a fenti CSV file kérésmintában látható. Az első sor adja meg a mezőneveket. A logikai értéket jelentő szöveg logikai értékké, a szokásos számszerű szöveg számmá alakul. A vezető nullával kezdődő értékek, a nem biztonságosan kezelhető nagy egész számok, a dátumok és az egyéb szövegek szövegként maradnak. Az üres cellák esetén a mező kimarad. A hibás formátumú sorokat, a nem lezárt idézőjeleket és az UTF-16 fájlokat a rendszer elutasítja.

Kérési korlátok és újrapróbálkozások

Előírás	Jelenlegi érték
Rekordok maximális száma	10 000 kérésenként
Kérés törzsének maximális mérete	10 MB
Szervezetenkénti kérési gyakoriság	600 kérés 60 másodpercenként

A nagyobb exportokat ossza fel úgy, hogy a kötegek mindkét korlátnak megfeleljenek. Várja meg az egyes válaszokat, és a visszaadott runId értéket őrizze meg a küldő naplóiban.

Válasz	Jelentés	Teendő a küldő oldalán
`202`	A köteg elfogadva	Rögzítse a következőt: `runId`; ne küldje újra azonnal
`400`	Érvénytelen név, JSON, CSV, rekordszám vagy törzs	Javítsa a kérést; ne próbálkozzon újra változatlanul
`401`	Hiányzó, lejárt, visszavont vagy érvénytelen kulcs	Cserélje le a kulcsot, és használja a Bearer fejlécet
`403`	A kulcs nem rendelkezik a szükséges hatókörrel	Hozzon létre Push Ingest hatókörű kulcsot
`404`	A forrás vagy az adatfolyam nincs regisztrálva	Regisztrálja a pontos párt, vagy javítsa az URL-t
`413`	A kérés törzse meghaladja a 10 MB-ot	Ossza fel a köteget kisebb kérésekre
`429`	Ideiglenes IP-szintű korlátozás	Ha van, vegye figyelembe a következőt: `Retry-After`, és várjon az újrapróbálkozással
`503`	A szervezeti kérési keret vagy a korlátozó nem érhető el	Várjon a következőig: `Retry-After`, majd küldje újra ugyanazt a köteget

A szervezetre vonatkozó szokásos, hitelesített korlát 503 választ ad, nem 429 választ, így a webhook-küldők újrapróbálhatónak kezelik. A 503 válasz a köteg tárolása előtt érkezik; ugyanannak a kötegnek a megadott időköz utáni újraküldése nem duplikálja az elfogadott futtatást.

Az adatáramlás ellenőrzése

Nyissa meg a Custom Push Source forrást, és tekintse át a Push History nézetet. Ellenőrizze az adatfolyamot, a rekordszámot, a kulcshoz rendelést és a feldolgozási állapotot. A karbantartott értelmezővel rendelkező adatokból ezt követően személyek és normalizált tevékenység jöhet létre. Az értelmező nélküli adatok tárolva maradnak, de nem hoznak létre tevékenységet.

Ha létezik szolgáltatóspecifikus útmutató, használja annak pontos mezőneveit és adatszerkezetét. A sikeres 202 a kézbesítést igazolja, nem azt, hogy egy tetszőleges séma leképezhető Living Security tevékenységre.

Hibaelhárítási ellenőrzőlista

Másolja ki a végpontot a megfelelő forrásból, és cserélje le az adatfolyam helyőrzőjét.
A hozzáférési kulcsot Authorization: Bearer … formában küldje; a x-api-key nem fogadható el.
Ellenőrizze, hogy a törzs legfelső szintű JSON-tömb, nem pedig egyetlen objektum vagy a rekordokat körülvevő burkoló.
Ellenőrizze a forrás és az adatfolyam helyesírását, beleértve a kötőjeleket, az aláhúzásjeleket és a kis- és nagybetűket.
Mielőtt újraküld egy olyan köteget, amelynek a válasza elveszett, tekintse át a Push History nézetet.
Ha felveszi a kapcsolatot a Living Security ügyfélszolgálatával, adja meg a szervezetet, a forrást, az adatfolyamot, a kérés időpontját, ha elérhető, a következőt: runId, valamint a válasz állapotát. Ne mellékelje a hozzáférési kulcsot vagy az esemény adattartalmát.

Kapcsolódó

Zscaler ZIA Cloud NSS

Konfiguráljon egy támogatott Zscaler webnapló-folyamot a pontos forrással, adatfolyammal, fejlécekkel és JSON-szerkezettel.

API-hozzáférési kulcsok

Hatókörhöz kötött hitelesítő adatok létrehozása, forgatása és visszavonása.

Jelzések adatforrásai

Ismerje meg, hogyan támogatja az értelmezett integrációs tevékenység a jelzéseket.

Integrációk

Integráció beállítása

Katalógus

Kimenő csatornák

Előkészületek

1. A forrás és az adatfolyamok regisztrálása

2. Push-ingest kulcs létrehozása

3. A regionális végpont kiválasztása

Kérés törzse

4. JSON-köteg küldése

CSV küldése helyette

Kérési korlátok és újrapróbálkozások

Az adatáramlás ellenőrzése

Hibaelhárítási ellenőrzőlista

Kapcsolódó

Zscaler ZIA Cloud NSS

API-hozzáférési kulcsok

Jelzések adatforrásai

Integrációk

Integráció beállítása

Katalógus

Kimenő csatornák

​Előkészületek

​1. A forrás és az adatfolyamok regisztrálása

​2. Push-ingest kulcs létrehozása

​3. A regionális végpont kiválasztása

​Kérés törzse

​4. JSON-köteg küldése

​CSV küldése helyette

​Kérési korlátok és újrapróbálkozások

​Az adatáramlás ellenőrzése

​Hibaelhárítási ellenőrzőlista

​Kapcsolódó

Zscaler ZIA Cloud NSS

API-hozzáférési kulcsok

Jelzések adatforrásai

Előkészületek

1. A forrás és az adatfolyamok regisztrálása

2. Push-ingest kulcs létrehozása

3. A regionális végpont kiválasztása

Kérés törzse

4. JSON-köteg küldése

CSV küldése helyette

Kérési korlátok és újrapróbálkozások

Az adatáramlás ellenőrzése

Hibaelhárítási ellenőrzőlista

Kapcsolódó