API and integrations guide

For console 2.17.4 · updated 2026-11-03

Your ByteMantle console already shows every attack your people's browsers met: the fake "verify you are human" pages, the phishing sign-ins, the commands a page tried to slip onto the clipboard, the incidents they formed. This guide is about getting that information out of the console and into the tools you already use — your SIEM, a spreadsheet, a ticket system, a dashboard, a script of your own, or an AI assistant that helps your security team.

There are two ways to do it, and most organizations use one or both:

Only administrators of your organization can set up either one: the SIEM and API Keys pages are not in the menu of viewers and analysts. Both work only over HTTPS and only with your own organization's data.

Every command and script in this guide is run against a ByteMantle console before each release, and SIEM delivery is checked in all three formats by a receiver that inspects each delivery the way a SIEM does. The screenshots come from a demonstration console with sample data. If something does not work the way it is written here, tell us: that is a bug in the guide.

1. Send your threat events to your SIEM (10 minutes)

What you need: an HTTPS address on your SIEM side that accepts events, and the header it uses to authenticate (for Splunk, an HTTP Event Collector token).

1. In the console, open Admin → SIEM.

   

2. Under Add destination, fill in:
   • Name — anything that tells you what it is, e.g. "Splunk production".
   • Endpoint URL — your SIEM's HTTPS address. For Splunk it ends in /services/collector/event (for example https://splunk.example.com:8088/services/collector/event).
   • Format — Splunk HEC for Splunk; JSON batch for Elastic, a Logic App or any webhook; CEF lines for a syslog relay.
   • Minimum severity — start with Medium or High if you only want what matters most.
   • Auth header name / value — for Splunk: Authorization and Splunk <your HEC token>. The value is stored encrypted and is never shown again, not even to you.
   • Event types — leave empty to receive every kind of threat event.

   

3. Click Add destination, then Send test next to it. Your SIEM should receive one sample event within seconds. If it does not, the page shows the error your SIEM answered.

   

That is all. From now on the console sends new threat events every minute, in batches of up to 100. If your SIEM is unavailable, nothing is lost: the console tries again, waiting a little longer each time, and continues where it stopped. What exactly is sent, field by field, is in 4.8.

↑ Top

2. Your first API call (5 minutes)

What you need: a computer with curl (it is part of Windows 10 and 11, macOS and Linux).

Step 1 — create a key. In the console, open Admin → API Keys, give the key a name that says what will use it, and choose:

• Acts as: Viewer is enough for almost everything. Analyst is only needed if the key must also read the evidence text of events (the actual command a page tried to copy), and then you also tick Allow sensitive properties (with Viewer, the console refuses that box with a message).
• Data types: leave them all unticked to allow everything the role may read, or tick only what the integration needs.
• Allowed IP addresses: the address of the server that will use the key. Strongly recommended.
• Expires on: keys expire after a year by default; you can choose another date or none. The key works until the end of that day in the console's time zone.

Click Create key. The key appears once: copy it now and keep it in your password manager or secret store. The console keeps only a fingerprint of it, so nobody — not even ByteMantle — can show it to you again. If you lose it, create a new one and revoke the old one.

Step 2 — ask what you may read. Put the key in a variable (so it does not end up in your shell history twice) and call the catalog:

export BYTEMANTLE_KEY='ngk_paste-your-key-here'
curl -s -H "Authorization: Bearer $BYTEMANTLE_KEY" https://console.bytemantle.com/api/v1/catalog.php

You get back the list of data types your key can read, with every field of each one (the full list is in 4.7).

Step 3 — ask for the high and critical events.

curl -s https://console.bytemantle.com/api/v1/query.php \
  -H "Authorization: Bearer $BYTEMANTLE_KEY" -H "Content-Type: application/json" \
  -d '{"type": "core.event",
       "columns": ["event_time", "severity", "event_type", "site", "device.label", "action"],
       "filters": [{"p": "severity", "op": "gte", "v": "high"}],
       "sort": [{"p": "event_time", "dir": "desc"}],
       "limit": 2}'

The answer, exactly as the console sent it:

{
  "ok": true,
  "type": "core.event",
  "columns": [
    {"name": "event_time", "type": "datetime", "label": "Time"},
    {"name": "severity", "type": "enum", "label": "Severity"},
    {"name": "event_type", "type": "enum", "label": "Type"},
    {"name": "site", "type": "domain", "label": "Site"},
    {"name": "device__label", "type": "text", "label": "Label"},
    {"name": "action", "type": "text", "label": "Action"}
  ],
  "rows": [
    {"event_time": "2026-11-03T12:44:02Z", "severity": "critical", "event_type": "service_worker", "site": "swu-zz.com",
     "device__label": "Linux · Chrome · #0023", "action": "detected"},
    {"event_time": "2026-11-03T12:44:02Z", "severity": "high", "event_type": "correlation", "site": "swu-zz.com",
     "device__label": "Linux · Chrome · #0023", "action": "detected"}
  ],
  "row_count": 2,
  "limit": 2,
  "truncated": false,
  "next_cursor": "eyJvIjoyLCJxIjoiNTkwMTY3Njg0ZTg3NDYyYSJ9",
  "took_ms": 2
}

Three things to notice: device.label comes back as device__label (a field of a related object); times are always UTC; and next_cursor means more rows are waiting — 4.5 shows how to read them.

↑ Top

3. Recipes

Each recipe is complete: copy it, set BYTEMANTLE_KEY (and change console.bytemantle.com if your console has another address), and run it. The Python recipes need Python 3.9 or newer and the requests package (pip install requests).

3.1 Every event of the last 7 days into a CSV file (for Excel or Power BI)

import csv, os, requests

URL = "https://console.bytemantle.com/api/v1/query.php"
HEADERS = {"Authorization": "Bearer " + os.environ["BYTEMANTLE_KEY"]}
QUERY = {
    "type": "core.event",
    "columns": ["event_time", "severity", "event_type", "site", "url", "action", "blocked", "device.label", "incident_id"],
    "filters": [{"p": "event_time", "op": "last", "v": {"n": 7, "unit": "day"}}],
    "sort": [{"p": "event_time", "dir": "desc"}],
    "limit": 1000,
}

rows, cursor = [], None
while True:
    body = dict(QUERY, cursor=cursor) if cursor else QUERY
    answer = requests.post(URL, json=body, headers=HEADERS, timeout=60).json()
    if not answer["ok"]:
        raise SystemExit(f"The console refused the query: {answer}")
    rows += answer["rows"]
    cursor = answer["next_cursor"]
    if not cursor:
        break

with open("bytemantle_events.csv", "w", newline="", encoding="utf-8") as f:
    writer = csv.DictWriter(f, fieldnames=[c["name"] for c in answer["columns"]])
    writer.writeheader()
    writer.writerows(rows)
print(f"{len(rows)} events written to bytemantle_events.csv")

In Excel: Data → From Text/CSV and choose the file. In Power BI: Get data → Text/CSV. Run the script on a schedule (Task Scheduler, cron) to keep the file fresh.

3.2 A new ticket for every new incident

This script remembers the last incident it saw (in last_incident.txt) and prints every newer one as a line of JSON. Replace the print with a call to your ticket system's API (Jira, ServiceNow, a Teams or Slack webhook).

import json, os, pathlib, requests

URL = "https://console.bytemantle.com/api/v1/query.php"
HEADERS = {"Authorization": "Bearer " + os.environ["BYTEMANTLE_KEY"]}
STATE = pathlib.Path("last_incident.txt")
last_id = int(STATE.read_text()) if STATE.exists() else 0

answer = requests.post(URL, headers=HEADERS, timeout=60, json={
    "type": "core.incident",
    "columns": ["id", "title", "severity", "status", "site", "device.label", "first_seen_at", "last_seen_at", "event_count"],
    "filters": [{"p": "id", "op": "gt", "v": last_id}, {"p": "severity", "op": "gte", "v": "high"}],
    "sort": [{"p": "id", "dir": "asc"}],
    "limit": 100,
}).json()
if not answer["ok"]:
    raise SystemExit(f"The console refused the query: {answer}")

for incident in answer["rows"]:
    print(json.dumps(incident))          # here: open the ticket
    last_id = max(last_id, incident["id"])
STATE.write_text(str(last_id))
print(f"{len(answer['rows'])} new incident(s)")

Run it every few minutes. It asks only for incidents newer than the last one it handled, so a ticket is never opened twice.

3.3 How many events per day, and of which kind

Two queries for a chart. Events per day, last 7 days:

{"type": "core.event",
 "columns": [{"agg": "count", "as": "events"}],
 "group": [{"p": "event_time", "bucket": "day", "as": "day"}],
 "filters": [{"p": "event_time", "op": "last", "v": {"n": 7, "unit": "day"}}]}

Events per kind, last 30 days, most frequent first:

{"type": "core.event",
 "columns": ["event_type", {"agg": "count", "as": "events"}],
 "group": ["event_type"],
 "filters": [{"p": "event_time", "op": "last", "v": {"n": 30, "unit": "day"}}],
 "sort": [{"by": "events", "dir": "desc"}]}

Send either one the way step 3 of section 2 does (curl … -d '<the query>'). For long periods (months), ask core.event_summary instead of core.event: it holds hourly counts and answers much faster.

3.4 Open incidents, newest first

{"type": "core.incident",
 "columns": ["id", "title", "severity", "status", "site", "device.label", "last_seen_at"],
 "filters": [{"p": "status", "op": "in", "v": ["open", "investigating"]}],
 "sort": [{"p": "last_seen_at", "dir": "desc"}],
 "limit": 20}

3.5 One event, by its number

The id is the number in the event's address in the console (index.php?p=event&id=…).

curl -s -H "Authorization: Bearer $BYTEMANTLE_KEY" \
  "https://console.bytemantle.com/api/v1/query.php?type=core.event&id=241326&columns=event_time,severity,site,action"

3.6 Receive the SIEM events in your own service

If you do not use a SIEM but want the events pushed to a service of your own, choose the JSON batch format in section 1 and point it at a small receiver like this one. The console only sends to HTTPS addresses, so run it behind your HTTPS reverse proxy (nginx, IIS, a cloud load balancer) and set the same secret in the destination's Auth header (Authorization / Bearer <your secret>).

import hmac, json, os
from http.server import BaseHTTPRequestHandler, HTTPServer

SECRET = os.environ["RECEIVER_SECRET"]          # the value you also put in the console
PORT = int(os.environ.get("PORT", "8080"))

class Receiver(BaseHTTPRequestHandler):
    def do_POST(self):
        expected = "Bearer " + SECRET
        if not hmac.compare_digest(self.headers.get("Authorization", ""), expected):
            self.send_response(401); self.end_headers(); return
        batch = json.loads(self.rfile.read(int(self.headers["Content-Length"])))
        for event in batch["events"]:
            print(event["time"], event["severity"], event["type"], event["site"], event["event_id"], flush=True)
        self.send_response(204); self.end_headers()   # any 2xx answer tells the console the batch arrived

HTTPServer(("0.0.0.0", PORT), Receiver).serve_forever()

The console sends each batch until it gets a 2xx answer, so an event can occasionally arrive twice (for example after a network error): use event_id to recognise repeats.

3.7 ServiceNow: an incident for every ByteMantle incident

Most security teams track their work in ServiceNow. The simplest reliable way to connect ByteMantle to it is a small script that runs every few minutes: it asks ByteMantle for the open incidents, and creates an incident in ServiceNow for each one that is not there yet. ServiceNow's own Table API does the creating, so nothing has to be installed in ServiceNow.

What you need in ServiceNow (your ServiceNow administrator does this once):

• a user for the integration (for example bytemantle.integration), with a password and the itil role, which allows it to read and create incidents;
• your instance address, for example https://yourcompany.service-now.com.

What the script does:

• each ByteMantle incident becomes one ServiceNow incident: it is marked with correlation_id = bytemantle-<incident number>, and the script first asks ServiceNow whether that incident already exists, so running it again never creates duplicates;
• severity becomes urgency and impact: critical → 1 / 1, high → 2 / 2, medium → 3 / 2 (low and info incidents are left out);
• the description carries the site, the browser, when it started, how many events, and a link back to the incident in the console.

import os, requests

CONSOLE = "https://console.bytemantle.com"
BYTEMANTLE = {"Authorization": "Bearer " + os.environ["BYTEMANTLE_KEY"]}
SNOW = os.environ["SNOW_INSTANCE"].rstrip("/") + "/api/now/table/incident"     # e.g. https://yourcompany.service-now.com
SNOW_AUTH = (os.environ["SNOW_USER"], os.environ["SNOW_PASSWORD"])
JSON = {"Accept": "application/json"}
URGENCY_IMPACT = {"critical": ("1", "1"), "high": ("2", "2"), "medium": ("3", "2")}

answer = requests.post(CONSOLE + "/api/v1/query.php", headers=BYTEMANTLE, timeout=60, json={
    "type": "core.incident",
    "columns": ["id", "title", "severity", "site", "device.label", "first_seen_at", "event_count"],
    "filters": [{"p": "status", "op": "in", "v": ["open", "investigating"]},
                {"p": "severity", "op": "gte", "v": "medium"}],
    "sort": [{"p": "id", "dir": "asc"}],
    "limit": 100,
}).json()
if not answer["ok"]:
    raise SystemExit(f"ByteMantle refused the query: {answer}")

created = 0
for incident in answer["rows"]:
    correlation = f"bytemantle-{incident['id']}"
    found = requests.get(SNOW, auth=SNOW_AUTH, headers=JSON, timeout=30,
                         params={"sysparm_query": f"correlation_id={correlation}", "sysparm_fields": "sys_id", "sysparm_limit": "1"})
    found.raise_for_status()
    if found.json()["result"]:
        continue                                              # already in ServiceNow
    urgency, impact = URGENCY_IMPACT[incident["severity"]]
    reply = requests.post(SNOW, auth=SNOW_AUTH, headers=JSON, timeout=30, json={
        "short_description": "ByteMantle: " + incident["title"],
        "description": (f"Severity: {incident['severity']}\n"
                        f"Site: {incident['site']}\n"
                        f"Browser: {incident['device__label']}\n"
                        f"First seen (UTC): {incident['first_seen_at']}\n"
                        f"Threat events: {incident['event_count']}\n"
                        f"In the ByteMantle console: {CONSOLE}/index.php?p=incident&id={incident['id']}"),
        "urgency": urgency,
        "impact": impact,
        "correlation_id": correlation,
        "correlation_display": "ByteMantle",
    })
    reply.raise_for_status()
    created += 1
print(f"{created} incident(s) created in ServiceNow")

Set BYTEMANTLE_KEY, SNOW_INSTANCE, SNOW_USER and SNOW_PASSWORD as environment variables (or in your secret store), and run it every 5 minutes with Task Scheduler or cron.

Without a script. If your ServiceNow administrator prefers to receive events instead of fetching incidents, they can create a Scripted REST API in ServiceNow that accepts the JSON batch format of section 1 and add its address as a SIEM destination. The batch format is in 4.8. This sends every event (not incidents), so it suits event management better than incident tracking.

3.8 An AI assistant for your security team

An assistant that can make HTTP requests (a custom GPT action, a Copilot Studio connector, an agent you build) can use the Read API like any other client. Give it its own key, as Viewer, limited to the data types it needs (for example Incidents and Threat Events), with a low request limit and an expiry date. Describe the endpoints of 4.1 and the query format of 4.3 in its instructions, and it can answer questions like "which sites caused the most incidents this week?" from your own data. It can only read: no key can change anything in the console.

↑ Top

4. Reference

4.1 The three addresses

Every address starts with your console's address, for example https://console.bytemantle.com.

4.2 Authentication

Send the key in the Authorization header: Authorization: Bearer ngk_…. If something on your side removes that header (some proxies do), send X-NextGen-API-Key: ngk_… instead.

• Keys start with ngk_ followed by 48 hexadecimal characters.
• Your organization always comes from the key. A request never names an organization: a field called tenant anywhere in a request is refused (tenant_not_allowed).
• Requests over plain HTTP are refused. The API is for servers and scripts: it sends no CORS headers, so a web page in a browser cannot call it.
• A key can read, never change. It acts as a viewer or an analyst, never as an administrator: the audit log is not available through the API.
• Answers are JSON with Cache-Control: private, no-store.

The catalog, for a key limited to one data type (yours lists every type your key may read; this one is complete):

{
  "ok": true,
  "role": "viewer",
  "sensitive": false,
  "types": [
    {
      "id": "core.user", "label": "Users", "primary_key": "id", "time_property": null, "search": [], "max_rows": 1000,
      "properties": [
        {"id": "id", "label": "ID", "type": "integer",
         "operators": ["eq", "neq", "lt", "lte", "gt", "gte", "between", "in", "not_in", "is_null", "not_null"],
         "sortable": true, "groupable": false, "time_buckets": [], "aggregates": []},
        {"id": "username", "label": "Username", "type": "text",
         "operators": ["eq", "neq", "in", "not_in", "contains", "starts_with", "ends_with", "is_null", "not_null", "is_empty", "not_empty"],
         "sortable": true, "groupable": true, "time_buckets": [], "aggregates": []},
        {"id": "display_name", "label": "Name", "type": "text",
         "operators": ["eq", "neq", "in", "not_in", "contains", "starts_with", "ends_with", "is_null", "not_null", "is_empty", "not_empty"],
         "sortable": true, "groupable": false, "time_buckets": [], "aggregates": []}
      ],
      "relations": []
    }
  ],
  "aggregates": ["count", "count_distinct", "sum", "avg", "min", "max"],
  "limits": {"default_rows": 100, "max_rows": 1000, "max_response_bytes": 2097152, "max_body_bytes": 262144,
             "catalog_per_minute": 60, "query_per_minute": 120, "requests_per_day": 10000}
}

A field can also carry "values" (the possible values of a list field such as severity), "sensitive": true (readable only by an analyst key allowed to read sensitive data) and "requires_time_filter": true.

4.3 The query format

A query is one JSON object. Only type is required.

Times in values and answers are UTC, written as ISO 8601 (2026-11-03T12:44:02Z). A calculation is available on a field only when the field lists it under aggregates in the catalog (the calculations are count, count_distinct, sum, avg, min, max).

A query that combines conditions:

{"type": "core.event",
 "columns": ["id", "event_time", {"p": "site", "as": "domain"}, "incident.title"],
 "filters": [
   {"p": "event_time", "op": "last", "v": {"n": 30, "unit": "day"}},
   {"any": [{"p": "event_type", "op": "in", "v": ["clipboard", "phishing"]},
            {"not": {"p": "severity", "op": "lte", "v": "medium"}}]},
   {"p": "incident_id", "op": "not_null"}
 ],
 "limit": 5}

4.4 Operators

Which operators a field accepts is listed with the field in 4.7 (and in the catalog).

4.5 Reading more than one page

When more rows exist than fit in one answer, next_cursor is a string. Send the same query again with "cursor": "<next_cursor>" and you get the next page; stop when next_cursor is null (recipe 3.1 does exactly this). A cursor belongs to its query: if you change anything else in the query, the console refuses the cursor (bad_cursor) and you start again without one. Rows are never skipped or repeated between pages.

truncated: true means the console cut an answer at its size limit before limit rows; continue with next_cursor as usual.

4.6 Limits and errors

Limits keep one integration from slowing the console down for everyone. When you reach one, the answer says how long to wait.

Every error answer has the same shape — ok is false, error names the problem, message (most errors) explains it in words:

{"ok": false, "error": "invalid_query", "reason": "bad_operator", "message": "Operator contains is not allowed for Severity."}

rate_limited answers also carry scope (which limit) and retry_after_sec. The scopes:

invalid_query answers carry a reason:

4.7 Every data type and every field

For each data type: what it holds, what it needs, its key and time fields, the fields the free-text search looks in, the fields you get without columns, the related objects (use them as "relation.field", for example "device.label") and then every field. In the field tables: Ops = the operators the field accepts (empty = it cannot be filtered); Sort / Group = it can be sorted / grouped (time = grouped by hour, day, week or month); Calc = the calculations it offers.

core.event — Threat Events

Threat events reported by your browsers. The time field is event_time.

• Available with: every plan with the Read API; at most 1000 rows per answer.
• Key field: id; time field: event_time
• search looks in: event_id, hostname, site, url, rules_csv, evidence_sha256
• Without columns: event_time, severity, event_type, site, device.label, action, blocked
• Related objects: device → core.device (one), incident → core.incident (one), rules → core.event_rule (many: count them or filter with exists)

core.event_rule — Rule Matches

Which detection rule matched which event: one row per event and rule.

• Available with: every plan with the Read API; at most 1000 rows per answer.
• Key field: event_pk; time field: event_time
• search looks in: nothing (free-text search is not available)
• Without columns: every field
• Related objects: event → core.event (one)

core.device — Devices

Your enrolled browsers.

• Available with: every plan with the Read API; at most 1000 rows per answer.
• Key field: id; no time field
• search looks in: label, hostname, installation_id
• Without columns: label, status, extension_version, last_seen_at
• Related objects: incidents → core.incident (many: count them or filter with exists), events → core.event (many: count them or filter with exists)

core.incident — Incidents

Incidents: the threat events of one browser on one site within 30 minutes, grouped as one attack.

• Available with: every plan with the Read API; at most 1000 rows per answer.
• Key field: id; time field: last_seen_at
• search looks in: site, title
• Without columns: every field
• Related objects: device → core.device (one), assignee → core.user (one), events → core.event (many: count them or filter with exists)

core.user — Users

The people of your console (names only, for the assignee of incidents).

• Available with: every plan with the Read API; at most 1000 rows per answer.
• Key field: id; no time field
• search looks in: nothing (free-text search is not available)
• Without columns: every field
• Related objects: none

core.domain — Intelligence — Domains

Intelligence: every domain seen in your events or reported by your browsers, with its risk and verdict.

• Available with: the Intelligence feature; at most 1000 rows per answer.
• Key field: id; time field: last_seen_at
• search looks in: nothing (free-text search is not available)
• Without columns: every field
• Related objects: none

core.artifact — Artifacts

Files and scripts seen (by hash).

• Available with: the Artifacts feature; at most 1000 rows per answer.
• Key field: id; time field: last_seen_at
• search looks in: nothing (free-text search is not available)
• Without columns: every field
• Related objects: sample → core.event (one)

core.command — Commands

Commands that pages tried to put on the clipboard (by hash), with what they would have done.

• Available with: every plan with the Read API; at most 1000 rows per answer.
• Key field: id; time field: last_seen_at
• search looks in: cmd_hash, template_hash, payload_hosts
• Without columns: last_seen_at, interpreter, write_class, events, detected_only, cmd_hash
• Related objects: none

core.resource — Resource Lineage

Resource lineage: which page loaded which resource.

• Available with: the Resource Lineage feature; at most 1000 rows per answer.
• Key field: id; time field: last_seen_at
• search looks in: resource_site, page_site, resource_url
• Without columns: every field
• Related objects: none

core.rpc_endpoint — Web3 — RPC Endpoints

Web3: the blockchain RPC endpoints pages talked to.

• Available with: the Web3 feature; at most 1000 rows per answer.
• Key field: id; time field: last_seen_at
• search looks in: endpoint_host, provider, sites_csv
• Without columns: every field
• Related objects: none

core.web3_contract — Web3 — Contracts

Web3: smart contracts pages read or called.

• Available with: the Web3 feature; at most 1000 rows per answer.
• Key field: id; time field: last_seen_at
• search looks in: address, contract_key, contract_name, websites_json
• Without columns: every field
• Related objects: none

core.web3_contract_device — Web3 — Contract sightings

Web3: which browser met which contract.

• Available with: the Web3 feature; at most 1000 rows per answer.
• Key field: contract_id; time field: last_seen_at
• search looks in: nothing (free-text search is not available)
• Without columns: every field
• Related objects: device → core.device (one), contract → core.web3_contract (one)

core.audit — Audit Log

The audit log. Not available through the API (it is for administrators).

core.telemetry — Telemetry

Telemetry records (only when your organization collects telemetry); same fields as threat events.

• Available with: every plan with the Read API; at most 1000 rows per answer.
• Key field: id; time field: event_time
• search looks in: event_id, hostname, site, url, rules_csv, evidence_sha256
• Without columns: event_time, event_type, site, device.label, resource_count
• Related objects: device → core.device (one)

core.event_summary — Event summary (hourly)

Hourly counts of threat events: fast for long time ranges.

• Available with: every plan with the Read API; at most 1000 rows per answer.
• Key field: hour; time field: hour
• search looks in: nothing (free-text search is not available)
• Without columns: hour, event_type, severity, action, n
• Related objects: none

Event types

The values of event_type (threat events and telemetry):

A newer browser extension may report a type that is not in this list yet; the API returns it as it is.

4.8 What the SIEM receives

Up to 5 destinations per organization. Every minute the console sends the new threat events in batches of up to 100, oldest first (events younger than 15 seconds wait for the next minute). It moves on only after a 2xx answer; after an error it tries again later, waiting longer each time and respecting a Retry-After header. It sends only to HTTPS addresses on the public internet, does not follow redirects and connects to the address it checked. The evidence itself (for example the command a page tried to copy) is never sent, only its SHA-256.

Formats:

• json — JSON batch (generic webhook, Elastic, Logic Apps)
• splunk_hec — Splunk HTTP Event Collector
• cef — CEF lines (text/plain)

Every event becomes one record with these fields:

A JSON batch, exactly as a console sent it:

{
  "source": "nextgen-console",
  "count": 2,
  "events": [
    {
      "vendor": "ByteMantle",
      "product": "ByteMantle Console",
      "console_version": "2.14.1",
      "tenant_id": "1",
      "tenant": "Contoso",
      "id": "241328",
      "event_id": "ngav-1793709842735-4hdr7nlf",
      "type": "correlation",
      "telemetry": false,
      "time": "2026-11-03T12:44:02+00:00",
      "received": "2026-11-03T12:44:02+00:00",
      "severity": "high",
      "action": "detected",
      "blocked": false,
      "url": "http://lure2.swu-zz.com:18766/",
      "host": "lure2.swu-zz.com",
      "site": "swu-zz.com",
      "source": "temporal_correlation",
      "confidence": 0.8,
      "score": null,
      "rules": [
        "sw_on_flagged_site_chain"
      ],
      "mitre": [
        "T1189",
        "T1204.004"
      ],
      "evidence_sha256": null,
      "incident_id": "382",
      "correlation_id": null,
      "device": {
        "id": "245",
        "hostname": null,
        "label": "Linux · Chrome · #0023",
        "extension_version": "3.12.4"
      }
    },
    {
      "vendor": "ByteMantle",
      "product": "ByteMantle Console",
      "console_version": "2.14.1",
      "tenant_id": "1",
      "tenant": "Contoso",
      "id": "241327",
      "event_id": "ngav-1793709842731-ptspuqj0",
      "type": "service_worker",
      "telemetry": false,
      "time": "2026-11-03T12:44:02+00:00",
      "received": "2026-11-03T12:44:02+00:00",
      "severity": "info",
      "action": "remediated",
      "blocked": false,
      "url": "http://lure2.swu-zz.com:18766/",
      "host": "lure2.swu-zz.com",
      "site": "swu-zz.com",
      "source": "service_worker",
      "confidence": null,
      "score": null,
      "rules": [
        "sw.unload.auto"
      ],
      "mitre": [],
      "evidence_sha256": null,
      "incident_id": "382",
      "correlation_id": null,
      "device": {
        "id": "245",
        "hostname": null,
        "label": "Linux · Chrome · #0023",
        "extension_version": "3.12.4"
      }
    }
  ]
}

Splunk HEC: one line per event, each a JSON object with time (Unix seconds), host (the browser), source, sourcetype (nextgen:event) and event (the record above):

{"time":1793709842,"host":"Linux · Chrome · #0023","source":"nextgen-console","sourcetype":"nextgen:event","event":{"vendor":"ByteMantle","product":"ByteMantle Console","console_version":"2.14.1","tenant_id":"1","tenant":"Contoso","id":"241328","event_id":"ngav-1793709842735-4hdr7nlf","type":"correlation","telemetry":false,"time":"2026-11-03T12:44:02+00:00","received":"2026-11-03T12:44:02+00:00","severity":"high","action":"detected","blocked":false,"url":"http://lure2.swu-zz.com:18766/","host":"lure2.swu-zz.com","site":"swu-zz.com","source":"temporal_correlation","confidence":0.8,"score":null,"rules":["sw_on_flagged_site_chain"],"mitre":["T1189","T1204.004"],"evidence_sha256":null,"incident_id":"382","correlation_id":null,"device":{"id":"245","hostname":null,"label":"Linux · Chrome · #0023","extension_version":"3.12.4"}}}
{"time":1793709842,"host":"Linux · Chrome · #0023","source":"nextgen-console","sourcetype":"nextgen:event","event":{"vendor":"ByteMantle","product":"ByteMantle Console","console_version":"2.14.1","tenant_id":"1","tenant":"Contoso","id":"241327","event_id":"ngav-1793709842731-ptspuqj0","type":"service_worker","telemetry":false,"time":"2026-11-03T12:44:02+00:00","received":"2026-11-03T12:44:02+00:00","severity":"info","action":"remediated","blocked":false,"url":"http://lure2.swu-zz.com:18766/","host":"lure2.swu-zz.com","site":"swu-zz.com","source":"service_worker","confidence":null,"score":null,"rules":["sw.unload.auto"],"mitre":[],"evidence_sha256":null,"incident_id":"382","correlation_id":null,"device":{"id":"245","hostname":null,"label":"Linux · Chrome · #0023","extension_version":"3.12.4"}}}

CEF: one line per event (severity: info 1, low 3, medium 5, high 8, critical 10):

CEF:0|ByteMantle|ByteMantle|2.14.1|correlation|correlation on swu-zz.com|8|rt=1793709842000 request=http://lure2.swu-zz.com:18766/ dhost=lure2.swu-zz.com shost=Linux · Chrome · #0023 act=detected externalId=ngav-1793709842735-4hdr7nlf cs1Label=tenant cs1=Contoso cs2Label=rules cs2=sw_on_flagged_site_chain cs3Label=mitre cs3=T1189,T1204.004
CEF:0|ByteMantle|ByteMantle|2.14.1|service_worker|service_worker on swu-zz.com|1|rt=1793709842000 request=http://lure2.swu-zz.com:18766/ dhost=lure2.swu-zz.com shost=Linux · Chrome · #0023 act=remediated externalId=ngav-1793709842731-ptspuqj0 cs1Label=tenant cs1=Contoso cs2Label=rules cs2=sw.unload.auto cs3Label=mitre

↑ Top

5. Versions and changes

This is version 1 of the Read API (/api/v1/). New data types, fields and error codes may be added in later console versions; existing ones keep their name and meaning within version 1. Your console's catalog always describes what your version offers. The changes of each console version are in its release notes.