API Custom Push Source

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"
}

Utilisez une Custom Push Source lorsqu’un système envoie des enregistrements à Living Security au lieu d’être interrogé par un connecteur du Catalogue. L’émetteur peut soumettre des tableaux JSON ou des fichiers CSV à un point de terminaison HTTPS régional.

Avant de commencer

Vous avez besoin des éléments suivants :

l’autorisation de gérer les intégrations et les clés d’accès dans Living Security
un émetteur côté serveur capable d’effectuer des requêtes HTTPS POST
la région Living Security de votre organisation
un nom de source stable et au moins un nom de flux

Les noms de source et de flux sont des clés de routage permanentes. Les noms de source doivent comporter de 1 à 64 lettres minuscules, chiffres ou traits d’union. Les noms de flux autorisent également les traits de soulignement. Les deux doivent commencer par une lettre ou un chiffre.

Traitez la clé d’accès API comme un secret. Ne la placez pas dans du code exécuté dans le navigateur, ne l’enregistrez pas dans un système de gestion de versions et ne l’envoyez pas dans un ticket d’assistance.

1. Enregistrer la source et les flux

Ouvrir Custom Push Source

Accédez à Paramètres → Intégrations → Catalogue, recherchez Custom Push Source, puis sélectionnez Ajouter.

Nommer la source

Saisissez la clé de routage de la source et, si vous le souhaitez, une description. Utilisez par exemple custom-phishing-sim plutôt qu’un nom d’affichage contenant des espaces.

Ajouter des flux

Ajoutez chaque flux que l’émetteur utilisera. Le couple source/flux doit exister avant le premier envoi ; un couple inconnu renvoie 404 Not Found.

Enregistrer la source

Une fois la source créée, ouvrez-la sous Paramètres → Intégrations → Connecté. Sa vue Push via API affiche le modèle de point de terminaison et les exécutions récentes.

2. Créer une clé d’ingestion par envoi

Accédez à Paramètres → Access Keys, sélectionnez Create Access Key, puis choisissez la portée Push Ingest. Copiez immédiatement la valeur générée ; elle n’est affichée qu’une seule fois. La clé est liée à une seule organisation Living Security. La requête d’envoi n’a pas besoin d’en-tête d’organisation. Consultez Clés d’accès API pour la rotation et la révocation.

3. Choisir le point de terminaison régional

Utilisez le nom d’hôte correspondant à l’organisation Living Security :

Région	URL de base
États-Unis	`https://api.us-east-1.livingsecurity.ai/api/v1`
Union européenne	`https://api.eu-west-1.livingsecurity.ai/api/v1`

Ajoutez /push-ingest/{integrationKey}/{streamName}. Le chemin est sensible à la casse et doit correspondre exactement à la source et au flux enregistrés.

string

requis

Nom de la source enregistrée. Utilisez de 1 à 64 lettres minuscules, chiffres ou traits d’union, en commençant par une lettre ou un chiffre.

string

requis

Nom du flux enregistré. Les mêmes règles s’appliquent, et les traits de soulignement sont également autorisés.

string

requis

Envoyez la clé d’accès d’ingestion par envoi sous la forme Bearer <access-key>.

string

Utilisez application/json pour le JSON ou text/csv pour le CSV. Le serveur peut également détecter un tableau JSON lorsque cet en-tête est omis.

string

UUID d’organisation facultatif. La clé d’accès détermine déjà l’organisation. Si vous envoyez cet en-tête, il doit correspondre à l’organisation de la clé ; il ne permet pas de sélectionner une autre organisation.

Corps de la requête

Envoyez un tableau JSON de niveau supérieur, non vide, composé d’objets, ou les octets d’un fichier CSV comportant une ligne d’en-tête. Il n’existe aucun champ d’enveloppe JSON nommé. Chaque lot peut contenir jusqu’à 10,000 enregistrements et 10 MB.

4. Envoyer un lot JSON

Envoyez un tableau JSON non vide dont les éléments sont des objets. Content-Type: application/json est recommandé et requis par de nombreux produits émetteurs, même si Living Security peut détecter un corps de type tableau sans cet en-tête.

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'

Une requête réussie renvoie 202 Accepted. L’onglet d’erreur affiche un 400 Bad Request lorsque le corps JSON est mal formé :

{
  "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"
}

L’acceptation signifie que le lot a été stocké en vue d’un traitement asynchrone. Elle ne signifie pas que chaque enregistrement a déjà été interprété en activité. Pour l’exemple 400, corrigez le JSON ou envoyez du CSV avec Content-Type: text/csv, puis réessayez.

string

requis

Identifiant d’exécution de ce lot accepté. Conservez-le pour vérifier l’état du traitement.

number

requis

Nombre d’enregistrements acceptés et stockés.

string

requis

Nom de la source utilisée pour cet envoi.

string

requis

Nom du flux utilisé pour cet envoi.

Envoyer du CSV à la place

Définissez Content-Type: text/csv et envoyez les octets du fichier, comme indiqué dans l’exemple de requête CSV file ci-dessus. La première ligne fournit les noms des champs. Le texte booléen devient un booléen et le texte numérique ordinaire devient un nombre. Les valeurs commençant par un zéro, les grands entiers non sûrs, les dates et les autres textes restent des chaînes de caractères. Une cellule vide entraîne l’omission du champ. Les lignes mal formées, les guillemets non équilibrés et les fichiers UTF-16 sont rejetés.

Limites des requêtes et nouvelles tentatives

Contrat	Valeur actuelle
Nombre maximal d’enregistrements	10,000 par requête
Taille maximale du corps de la requête	10 MB
Débit de requêtes par organisation	600 requêtes par 60 secondes

Scindez les exports plus volumineux en lots respectant ces deux limites. Attendez chaque réponse et conservez le runId renvoyé dans les journaux de l’émetteur.

Réponse	Signification	Action de l’émetteur
`202`	Lot accepté	Enregistrez le `runId` ; ne renvoyez pas immédiatement
`400`	Nom, JSON, CSV, nombre d’enregistrements ou corps non valide	Corrigez la requête ; ne la relancez pas à l’identique
`401`	Clé manquante, expirée, révoquée ou non valide	Remplacez la clé et utilisez l’en-tête Bearer
`403`	La clé ne dispose pas de la portée requise	Créez une clé avec la portée Push Ingest
`404`	La source ou le flux n’est pas enregistré	Enregistrez le couple exact ou corrigez l’URL
`413`	Le corps de la requête dépasse 10 MB	Scindez le lot en requêtes plus petites
`429`	Limitation temporaire au niveau de l’adresse IP	Respectez `Retry-After` s’il est présent et temporisez
`503`	Compartiment de débit de l’organisation ou limiteur indisponible	Attendez `Retry-After`, puis renvoyez le même lot

La limite normale d’une organisation authentifiée renvoie 503, et non 429, de sorte que les émetteurs de webhooks la traitent comme pouvant être réessayée. Un 503 est renvoyé avant le stockage du lot ; renvoyer ce même lot après l’intervalle indiqué ne duplique pas une exécution acceptée.

Vérifier le flux de données

Ouvrez la Custom Push Source et consultez Push History. Vérifiez le flux, le nombre d’enregistrements, l’attribution de la clé et l’état du traitement. Les données disposant d’un interpréteur maintenu peuvent ensuite devenir des personnes et des activités normalisées. Les données sans interpréteur restent stockées mais ne produisent aucune activité.

Utilisez les noms de champs et la structure de charge utile exacts du guide propre au fournisseur, lorsqu’il en existe un. Un 202 réussi prouve la livraison, et non qu’un schéma arbitraire correspond à une activité Living Security.

Liste de contrôle de dépannage

Copiez le point de terminaison depuis la source appropriée et remplacez l’espace réservé du flux.
Envoyez la clé d’accès sous la forme Authorization: Bearer … ; x-api-key n’est pas accepté.
Vérifiez que le corps est un tableau JSON de niveau supérieur, et non un objet unique ni une enveloppe autour des enregistrements.
Vérifiez l’orthographe de la source et du flux, y compris les traits d’union, les traits de soulignement et la casse.
Consultez Push History avant de renvoyer un lot dont la réponse a été perdue.
Lorsque vous contactez l’assistance Living Security, indiquez l’organisation, la source, le flux, l’heure de la requête, le runId lorsqu’il est disponible, ainsi que le statut de la réponse. N’incluez ni la clé d’accès ni la charge utile des événements.

Voir aussi

Zscaler ZIA Cloud NSS

Configurez un flux de journaux web Zscaler pris en charge avec la source, le flux, les en-têtes et la structure JSON exacts.

Clés d'accès API

Créez, renouvelez et révoquez des identifiants à portée limitée.

Sources de données des Signaux

Découvrez comment l’activité interprétée des intégrations alimente les Signaux.

Intégrations

Configuration des intégrations

Catalogue

Canaux sortants

Avant de commencer

1. Enregistrer la source et les flux

2. Créer une clé d’ingestion par envoi

3. Choisir le point de terminaison régional

Corps de la requête

4. Envoyer un lot JSON

Envoyer du CSV à la place

Limites des requêtes et nouvelles tentatives

Vérifier le flux de données

Liste de contrôle de dépannage

Voir aussi

Zscaler ZIA Cloud NSS

Clés d'accès API

Sources de données des Signaux

Intégrations

Configuration des intégrations

Catalogue

Canaux sortants

​Avant de commencer

​1. Enregistrer la source et les flux

​2. Créer une clé d’ingestion par envoi

​3. Choisir le point de terminaison régional

​Corps de la requête

​4. Envoyer un lot JSON

​Envoyer du CSV à la place

​Limites des requêtes et nouvelles tentatives

​Vérifier le flux de données

​Liste de contrôle de dépannage

​Voir aussi

Zscaler ZIA Cloud NSS

Clés d'accès API

Sources de données des Signaux

Avant de commencer

1. Enregistrer la source et les flux

2. Créer une clé d’ingestion par envoi

3. Choisir le point de terminaison régional

Corps de la requête

4. Envoyer un lot JSON

Envoyer du CSV à la place

Limites des requêtes et nouvelles tentatives

Vérifier le flux de données

Liste de contrôle de dépannage

Voir aussi