Webhook

Send logs to Jutsu from anything that can make an HTTP request: a syslog daemon collecting from your appliances, a log shipper you already run, or a product's "send logs to HTTP" export. You register a webhook in Jutsu and get one endpoint URL and a token. Nothing is installed anywhere. Events posted to the endpoint go through the same pipeline as agent traffic: normalization, detections, search, and retention.

Step 1 - Open Integrations#

Go to app.jutsu.ai and select Integrations in the left navigation. It sits under More. The Data Sources tab opens by default.

Step 2 - Select the Webhook card#

Scroll down to the Custom section and select the Webhook card. The Register a webhook dialog opens.

Step 3 - Register the webhook#

Under Collector name, replace the suggested http-webhook-01 with a name that says what will post to it, for example acme-app-logs. This is the name the webhook has in Jutsu.

The token accepts three source types: webhook.json, webhook.syslog, and webhook.text. Each record you send is typed on its own (see How records are typed). The webhook starts with a severity floor of info, so everything you send is visible to detection.

Select Create.

Register one webhook for each sender, or for each group of devices that share a sender. Creating it uses one connected-asset slot on your plan.

Step 4 - Copy the endpoint and token#

The Webhook registered dialog shows the endpoint, https://api.jutsu.ai/webhook, and the token. Jutsu shows the token only once, so select Copy token and store it where your sender's configuration will read it, before you select Close.

The endpoint reads three headers:

Content-Type isn't checked, so send whatever your sender sends. Bodies compressed with Content-Encoding: gzip are accepted.

Step 5 - Configure your sender#

Below the headers, the dialog has ready-made configuration for curl, rsyslog, syslog-ng, Fluent Bit, and Vector, with your endpoint and token already filled in. The curl tab has examples for a single JSON event, a JSON array, newline-delimited JSON, a syslog line, and Basic auth. Select Copy to copy one.

The same configurations follow, with jcol_YOUR_TOKEN_HERE in place of your token.

rsyslog (omhttp module, rsyslog 8.2001 or newer; it's the rsyslog-omhttp package on Debian and RHEL):

# /etc/rsyslog.d/60-jutsu.conf — POST https://api.jutsu.ai/webhook
module(load="omhttp")

action(
  type="omhttp"
  server="api.jutsu.ai"
  serverport="443"
  usehttps="on"
  # restpath takes the path WITHOUT a leading slash — omhttp adds it.
  restpath="webhook"
  httpheaders=["Authorization: Bearer jcol_YOUR_TOKEN_HERE"]
  batch="on"
  batch.format="newline"              # one syslog line per body line
  template="RSYSLOG_SyslogProtocol23Format"   # RFC5424: real timestamp + host
  action.resumeRetryCount="-1"        # never drop on a transient 5xx
  queue.type="LinkedList"
  queue.filename="jutsu_webhook"      # disk-assisted: survives a restart
  queue.maxDiskSpace="512m"
  queue.saveOnShutdown="on"
)

syslog-ng (http() destination):

# /etc/syslog-ng/conf.d/jutsu.conf
destination d_jutsu {
  http(
    url("https://api.jutsu.ai/webhook")
    method("POST")
    headers("Authorization: Bearer jcol_YOUR_TOKEN_HERE")
    body("<${PRI}>1 ${ISODATE} ${HOST} ${PROGRAM} ${PID} - - ${MSG}")
  );
};

log { source(s_local); destination(d_jutsu); };

Fluent Bit (http output):

# /etc/fluent-bit/fluent-bit.conf — POST https://api.jutsu.ai/webhook
[OUTPUT]
    name              http
    match             *
    host              api.jutsu.ai
    port              443
    tls               on
    uri               /webhook
    format            json
    header            Authorization Bearer jcol_YOUR_TOKEN_HERE
    json_date_key     timestamp
    json_date_format  iso8601

Vector (http sink):

sinks:
  jutsu_webhook:
    type: http
    inputs: [my_source]
    uri: "https://api.jutsu.ai/webhook"
    method: post
    compression: gzip
    encoding: { codec: json }
    framing:
      method: newline_delimited
    request:
      headers:
        Authorization: "Bearer jcol_YOUR_TOKEN_HERE"
        X-Source-Name: "<hostname>"
    batch: { max_events: 200, timeout_secs: 2 }
    buffer: { type: disk, max_size: 536870912, when_full: drop_newest }

At the bottom of the dialog, a note on Time explains how event times are read.

Send timestamps with a time zone: RFC5424 syslog, or JSON with an ISO 8601 timestamp. A classic RFC3164 syslog line (Sep 11 10:00:00 …) has no zone or year, so it is read as UTC in the current year. Keep devices that send that format on UTC. An event more than 5 minutes in the future is stamped with the time Jutsu received it instead.

Step 6 - Send a test event#

Send test event posts one event to the endpoint for you. Accepted — the endpoint took the event means the token works.

You can also test from your own network, which checks the same path your sender will use. To keep the token out of your shell history, read it into a variable first: run read -rs JUTSU_TOKEN && export JUTSU_TOKEN, paste the token, and press Enter. Then post a JSON event, a newline-delimited batch, and a syslog line:

curl -sS -o /dev/null -w '%{http_code}\n' https://api.jutsu.ai/webhook \
  -H "Authorization: Bearer $JUTSU_TOKEN" \
  -d '{"message":"checkout failed: card declined","host":"acme-app-01","user":"alex","severity":"warning"}'

curl -sS -o /dev/null -w '%{http_code}\n' https://api.jutsu.ai/webhook \
  -H "Authorization: Bearer $JUTSU_TOKEN" \
  --data-binary $'{"message":"user signed in","user":"alex"}\n{"message":"password reset requested","user":"jordan"}'

curl -sS -o /dev/null -w '%{http_code}\n' https://api.jutsu.ai/webhook \
  -H "Authorization: Bearer $JUTSU_TOKEN" \
  --data-binary "<38>1 $(date -u +%Y-%m-%dT%H:%M:%SZ) acme-edge-01 sshd 913 - - Failed password for root from 203.0.113.50 port 51122 ssh2"

Each request should print 200.

A 200 means every record in the request reached a durable buffer and will be written. A 401 means nothing was ingested: check the token and the Authorization header.

What you can send#

The endpoint reads the whole body as one document first, and line by line if that fails:

How records are typed#

Without an X-Source-Type header, each record gets one of the three types:

Because syslog lines are classified like agent logs, forwarded sshd and sudo lines produce the same events an agent would, and the built-in SSH detections run on them. An sshd Failed password line, for example, becomes a Medium Authentication event with the user, source IP, and port.

For JSON records, the first of these keys that is present fills each field:

Include a timestamp or a unique ID on every event. If a sender retries a request, Jutsu de-duplicates identical events on a best-effort basis only.

Verify the connection#

In Jutsu, open Connections. The webhook appears under Custom as Healthy, with Webhook under its name.

Open the webhook. Its header shows its health and when the last event arrived.

A webhook has no agent, so it has no heartbeat. Its health comes from deliveries: Healthy · Receiving within two minutes of the last event, and Healthy · Quiet within the hour after that. After an hour without events it shows Needs attention · No data in over an hour.

On the Overview, What's arriving counts the events of the last 24 hours by type.

The This webhook card repeats the endpoint and the headers, and Arriving as shows how many events arrived as each source type.

The Events tab lists the events as they arrive. The JSON events show their message, and the forwarded sshd line arrived as an Authentication Logon. Open an event to see all its fields.

Under Configure → Settings, the Details card lists the allowed source types and the minimum severity, which is All events (info) for a webhook.

If a chatty sender floods detection with routine events, raise Min severity here. Events below the floor are still kept in raw retention.

Troubleshooting#

Security and access#

• The token only accepts the three webhook source types, and Jutsu enforces that at ingest.
• Anyone who holds the token can post events as this webhook. Keep it off senders you don't control, and register a separate webhook for each sender so you can revoke one without affecting the others.
• Archiving or revoking stops the token within seconds. In rare cases, an old token can keep working for up to 30 minutes.
• A rejected request has already been uploaded before it's answered 401. It isn't ingested, but it still uses the sender's bandwidth.

Rotate the token#

On the webhook's page, open the ⋯ menu and select Rotate token. Choose a Grace window in minutes, from 0 to 1440 (the default is 60). The old token keeps working until the window ends, and 0 stops it immediately. Put the new token in your sender's configuration before the window ends.

Remove the webhook#

Archiving a webhook revokes its token in Jutsu. Then stop or re-point the sender, or it keeps retrying.

Step 1 - Archive the webhook#

Open the webhook, go to Configure → Danger zone, and select Archive collector.

Select Archive to confirm. Archiving stops ingest, frees the plan slot, and revokes the token. Events and alerts already collected stay searchable.

Step 2 - Stop the sender#

The Collector archived dialog reminds you to stop or re-point the sender. There's nothing to uninstall.

Remove the rsyslog omhttp action, the syslog-ng http() destination, the Fluent Bit [OUTPUT] block, or the Vector http sink. Until you do, the sender keeps posting and every request is answered 401.