Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/samkit511/SAW---Security-Analyst-Workspace/llms.txt

Use this file to discover all available pages before exploring further.

SAW accepts security logs through two routes: a dedicated /ingest-log endpoint for lightweight log shipping and the /assistant/request endpoint for full assistant-driven triage. Both routes run the same internal pipeline — your log is normalized, classified, and assigned an incident ID — but /ingest-log is simpler to integrate from external log forwarders, while /assistant/request gives you session continuity and explicit control over the request type.

​
Ingestion methods

The /ingest-log endpoint accepts either a structured JSON body or a raw plain-text log line. Use it when you want the lowest-friction way to push a log event into SAW.
1

Send a structured JSON log

Provide individual fields so SAW can normalize and enrich the event without parsing a raw string.
curl -X POST http://127.0.0.1:8080/ingest-log \
  -H "x-api-key: demo" \
  -H "Content-Type: application/json" \
  -H "x-event-id: evt-20240524-001" \
  -d '{
    "ip": "192.168.1.6",
    "method": "GET",
    "path": "/download",
    "payload": "../../etc/passwd",
    "source": "assistant_api"
  }'
FieldTypeDescription
ipstringSource IP address of the request
methodstringHTTP method (GET, POST, etc.)
pathstringRequest path
payloadstringRequest body or query string
rawstringPre-formatted log line (overrides field assembly)
sourcestringOrigin label; defaults to assistant_api
event_idstringIdempotency key; also readable from x-event-id header
2

Send a raw log line

If your log forwarder emits unstructured text, omit the Content-Type: application/json header and POST the raw bytes directly.
curl -X POST http://127.0.0.1:8080/ingest-log \
  -H "x-api-key: demo" \
  -H "x-event-id: evt-20240524-002" \
  --data-binary "ip=192.168.1.5 method=POST path=/login payload=admin' OR/**/1=1"
When the body is not JSON, SAW sets source to web_app_login_endpoint automatically and reads the x-event-id header as the event identifier.
3

Read the triage response

A successful ingest returns the full triage result:
{
  "request_id": "req_a1b2c3d4e5f6",
  "incident_id": "inc_7g8h9i0j1k2l",
  "workflow_status": "COMPLETED",
  "agent_summary": "Path traversal attempt detected. Request targets /etc/passwd via directory traversal in the payload.",
  "agent_results": {
    "RiskAgent": {
      "output": {
        "decision": {
          "action": "EXECUTE",
          "confidence": "HIGH",
          "reasoning": "Classic path traversal pattern identified."
        }
      }
    }
  },
  "meta": {
    "trace_id": "req_a1b2c3d4e5f6",
    "schema_version": "2.0.0",
    "system_metrics": {
      "latency_ms": 312
    }
  }
}
FieldDescription
request_idUnique ID for this specific API call
incident_idPersistent incident record created or updated
workflow_statusCOMPLETED or DEGRADED
agent_summaryHuman-readable summary from the agent pipeline
decisionOne of EXECUTE, OBSERVE, or IGNORE

​
Replay prevention with x-event-id

Include the x-event-id header (or the event_id field in a JSON body) on every request to prevent duplicate processing. SAW tracks event IDs for a 30-second window; a second request with the same ID within that window returns a 409 Conflict: 
{
  "error": {
    "code": "replay_detected",
    "message": "Duplicate event_id received within replay window.",
    "replay_window_seconds": 30
  }
}
Use a value that is unique per log event — a UUID, a hash of the raw log line, or a monotonically increasing counter all work well.
SAW enforces a rate limit of 12 requests per 60-second window per source IP across both /ingest-log and /assistant/request. When you exceed the limit, the API responds with HTTP 429 and a retry_after_seconds field indicating how long to wait before retrying.

Build docs developers (and LLMs) love

Get started for freeTalk to us