> ## Documentation Index
> Fetch the complete documentation index at: https://docs.livingsecurity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Egyéni Push forrás API

> Regisztráljon egy forrást, és küldjön JSON- vagy CSV-formátumú eseménykötegeket a Living Security rendszerbe hatókörhöz kötött API-hozzáférési kulccsal.

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.

<Warning>
  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.
</Warning>

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

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## 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](/hu/features/settings/api-keys) 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.

<ParamField path="integrationKey" type="string" required>
  A regisztrált forrásnév. 1–64 kisbetűt, számjegyet vagy kötőjelet használjon, betűvel vagy számjeggyel kezdve.
</ParamField>

<ParamField path="streamName" type="string" required>
  A regisztrált adatfolyamnév. Ugyanezek a szabályok érvényesek, az aláhúzásjel is megengedett.
</ParamField>

<ParamField header="Authorization" type="string" required>
  A push-ingest hozzáférési kulcsot `Bearer <access-key>` formában küldje el.
</ParamField>

<ParamField header="Content-Type" type="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.
</ParamField>

<ParamField header="x-organization-id" type="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.
</ParamField>

### 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.

<RequestExample>
  ```bash JSON batch theme={null}
  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"
      }
    ]'
  ```

  ```bash CSV file theme={null}
  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'
  ```
</RequestExample>

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ú:

<ResponseExample>
  ```json 202 Accepted theme={null}
  {
    "runId": "01a0c45f-ae40-7e5f-8a9b-0c1d2e3f4a5b",
    "recordsAccepted": 1,
    "integrationKey": "custom-phishing-sim",
    "streamName": "events"
  }
  ```

  ```json 400 Invalid JSON theme={null}
  {
    "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"
  }
  ```
</ResponseExample>

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.

<ResponseField name="runId" type="string" required>
  Az elfogadott köteg futtatási azonosítója. Őrizze meg a feldolgozási állapot ellenőrzéséhez.
</ResponseField>

<ResponseField name="recordsAccepted" type="number" required>
  Az elfogadott és tárolt rekordok száma.
</ResponseField>

<ResponseField name="integrationKey" type="string" required>
  Az ehhez a küldéshez használt forrásnév.
</ResponseField>

<ResponseField name="streamName" type="string" required>
  Az ehhez a küldéshez használt adatfolyamnév.
</ResponseField>

## 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.

<Info>
  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.
</Info>

## 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](mailto:support@livingsecurity.com), 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ó

<CardGroup cols={2}>
  <Card title="Zscaler ZIA Cloud NSS" icon="shield" href="/hu/integrations/zscaler-zia-cloud-nss">
    Konfiguráljon egy támogatott Zscaler webnapló-folyamot a pontos forrással, adatfolyammal, fejlécekkel és JSON-szerkezettel.
  </Card>

  <Card title="API-hozzáférési kulcsok" icon="key" href="/hu/features/settings/api-keys">
    Hatókörhöz kötött hitelesítő adatok létrehozása, forgatása és visszavonása.
  </Card>

  <Card title="Jelzések adatforrásai" icon="wave-pulse" href="/hu/signals/data-sources">
    Ismerje meg, hogyan támogatja az értelmezett integrációs tevékenység a jelzéseket.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.