FortiAnalyzer's JSON-RPC API — a Community Docs Map (with your first call)

01What the repo is & why it's handy

rstierli/fortianalyzer-api-docs documents the FortiAnalyzer JSON-RPC API — 106 endpoints across 7 categories — generated from a Postman collection and published as a browsable site (Sphinx / Read the Docs). Each endpoint page carries a request/response example plus Python and cURL snippets. The categories mirror how you actually use FortiAnalyzer:

What it's convenient for: it's open (no FNDN login to browse), it's example-first (copy a working body instead of guessing the schema), and it's Postman-importable (drop the collection into Postman or Insomnia and start firing). Treat it as a quick, practical map that complements — not replaces — Fortinet's official reference: it is auto-generated and community-maintained, so verify the details against your own FortiAnalyzer build.

02How the JSON-RPC API works

Every request is an HTTP POST to a single endpoint, https://<faz>/jsonrpc. What you want to do is expressed inside the JSON body, not in the URL path. Four fields carry the whole call:

• method — the verb: exec (run an action, e.g. login), get (read), and add / set / update / delete (write).
• params[].url — the internal object path the verb acts on (e.g. /sys/login/user, /sys/status, /logview/adom/root/logsearch).
• params[].data — the payload for that path (only when needed).
• session — the token from login; null on the login call itself, then included on every request after.

JSON-RPC call = method + url + params (+ data) + session

One more concept: most read/report/log calls are ADOM-scoped — the ADOM name (often root) appears in the url, e.g. /logview/adom/root/logsearch.

03Your first call: log in, then reuse the session

Authentication is session-based. You exec the /sys/login/user path with a username and password; the response hands back a session token that every later call must carry.

POST https://faz.example.com/jsonrpc
Content-Type: application/json

{
  "method": "exec",
  "params": [{
    "url": "/sys/login/user",
    "data": { "user": "api_ro", "passwd": "<from-your-vault>" }
  }],
  "session": null,
  "id": 1
}

{
  "result": [{ "status": { "code": 0, "message": "OK" }, "url": "/sys/login/user" }],
  "session": "kLSFZ7qT9xZc1vB3rtKlXg==",
  "id": 1
}

Grab the session value and put it in the session field of the next request. A harmless read to prove you're in — fetch system status:

{
  "method": "get",
  "params": [{ "url": "/sys/status" }],
  "session": "kLSFZ7qT9xZc1vB3rtKlXg==",
  "id": 2
}

{
  "result": [{
    "status": { "code": 0, "message": "OK" },
    "url": "/sys/status",
    "data": { "Hostname": "FAZ-LAB", "Version": "v7.4.3-build...", "Serial-Number": "FAZ-VM..." }
  }],
  "id": 2
}

The same login, as a one-liner you can paste into a terminal:

curl -k -X POST "https://faz.example.com/jsonrpc" \
  -H "Content-Type: application/json" \
  -d '{"method":"exec","params":[{"url":"/sys/login/user","data":{"user":"api_ro","passwd":"'"$FAZ_PASS"'"}}],"session":null,"id":1}'

When you're done, close the session cleanly with exec /sys/logout so the token can't be reused.

04Map a task to a category

Once you're authenticated, the repo's categories tell you which path to call for a job:

• "Search the logs." LogView — add a task to /logview/adom/root/logsearch, note the returned task id (tid), then get the results by that id. (Log searches are asynchronous: create, then poll.)
• "Run / pull a report." Reports — trigger a layout and retrieve the generated output.
• "List devices / ADOMs." Device Manager — read /dvmdb/adom and the device tables.
• "Work with alerts." Incidents & Events — eventmgmt alerts and event handlers.

05Best practices

• Use a dedicated, least-privilege API admin — a read-only account (api_ro) for reporting/log pulls; grant write scopes only where a workflow truly needs them, and restrict it to the relevant ADOM(s).
• Keep credentials out of code. Read them from an environment variable or a vault at run time — see the secrets section — and never commit them or bake them into a Postman/Insomnia export.
• Verify TLS. The -k above is for a lab; in production trust the FortiAnalyzer certificate properly instead of skipping validation. (Issuing that cert: TLS Certificates from Linux.)
• Log out when finished (exec /sys/logout) and don't hold idle sessions open.
• Trust, but verify the docs. The repo is auto-generated — confirm exact parameters and behaviour against Fortinet's official reference and your FortiAnalyzer version.

06Where to go next

Browse the endpoint map at rstierli/fortianalyzer-api-docs, then drive these calls from a REST client with Insomnia as an API Remote Control (its FortiManager section uses the same JSON-RPC login pattern). Back to the Knowledge Base, or the Troubleshooting notes.