FortiManager’s JSON API allows centralized network-management workflows to be automated without reproducing every operation through the GUI. The API can retrieve managed objects, change configuration, execute operations, inspect status, and integrate FortiManager with orchestration systems. Its power comes from acting at the same management layer that already coordinates many FortiGate devices.
The NSE 6 FortiManager 7.6 Administrator explicitly includes FortiManager API concepts, supported methods, HTTP response handling, login and logout use cases, and retrieving policy-package installation targets. The important operational skill is building automation that is scoped, reviewable, and resilient rather than merely proving that an API call can change configuration.
FortiManager automation uses a JSON-RPC management model
FortiManager commonly accepts API requests through the /jsonrpc endpoint. Requests identify a method, parameters that include the target URL in the FortiManager object model, an identifier, and authentication context. The model is different from assuming every object has a conventional public REST endpoint.
Common operations include reading data, adding or changing objects, deleting configuration, and executing management actions. Exact URLs and object schemas vary by FortiManager version, which is why Fortinet directs administrators to the Fortinet Developer Network for detailed API documentation and version comparison.
Automation should therefore treat the API schema as a versioned contract. Do not hard-code assumptions from an old appliance and expect them to survive upgrades indefinitely. Test important workflows against the target release and verify changed fields or methods before production deployment.
Choose API-key or session-based authentication deliberately
Fortinet supports predefined API-key authentication using a REST API administrator, and session-based authentication using a regular administrator that has JSON API access. A predefined key can simplify machine-to-machine workflows because the caller does not need the login and logout endpoints for every session.
Session-based automation uses a login operation to obtain a session ID and should explicitly log out when finished. Fortinet warns that failing to release sessions can consume available administrator session slots and eventually deny management access until sessions expire or are cleared.
Both approaches require an appropriate admin profile. Authentication answers who the caller is; the admin profile controls what that identity can do. Use the narrowest ADOM and functional permissions that satisfy the automation requirement.
Trusted hosts and HTTPS are part of API design
API administrators should be restricted to trusted source networks where practical, and Fortinet recommends HTTPS for API communications. A permanent API key should be handled like a high-value secret because possession of the key can provide the permissions assigned to that administrator.
Do not embed keys or passwords casually in scripts, shared repositories, or automation logs. Use a secrets-management mechanism, rotate credentials according to policy, and separate read-only inventory jobs from write-capable configuration jobs when possible.
FortiManager can also log JSON API activity through its event logging controls. Audit data is important because automated changes can happen faster and at greater scale than interactive changes. A reliable automation platform must be able to explain which identity sent which request and what result FortiManager returned.
Read before write to reduce configuration risk
A safe workflow begins by querying current state and verifying that the object still matches the assumptions the automation was built on. For example, a job that changes a policy should confirm the correct ADOM, package, object identity, and installation target before writing.
This is the API equivalent of reviewing an Install Preview. If the current state is different from the expected precondition, the script should stop or require review instead of overwriting an administrator’s recent change. Idempotent automation aims to reach a desired state without creating unnecessary repeated changes.
For higher-risk workflows, store the pre-change state and the intended diff with the change record. Automation speed is useful only if the team can still reconstruct what happened later.
Asynchronous tasks are essential for long-running operations
Some FortiManager operations can create background tasks rather than forcing the API client to wait synchronously for completion. Fortinet’s API best-practice guidance describes using task-oriented flags such as create_task and nonblocking for supported operations.
The client must then monitor the task to completion and interpret the final result. Sending a request successfully is not the same as completing a device registration, refresh, or installation successfully. Automation that ignores the task result can report false success while FortiManager is still processing or has already failed.
At scale, asynchronous execution can improve throughput because multiple independent tasks can run without a single client connection blocking on each one. Concurrency must still be bounded so the manager and target devices are not overwhelmed.
Preview features can make automation reviewable
FortiManager 7.6 can preview configuration changes as JSON API or CLI for policy, object, and device-level edits in supported GUI workflows. That visibility is useful when translating manual processes into automation because it reveals how FortiManager represents the intended change.
Do not copy a preview blindly into production code. Use it to understand the object model, then build a minimal request with explicit parameters and error handling. A smaller request is easier to test and less likely to carry unrelated configuration.
The principles in network automation apply directly: repeatable workflows, clear inputs, deterministic behavior, and observable results matter more than the programming language used to send the request.
Error handling must include FortiManager status, not only HTTP
Because the API is a management RPC interface, a successful HTTP exchange does not automatically mean the requested configuration action succeeded. The client should parse FortiManager’s response status, message, returned data, and any task identifier.
Automation should classify errors into authentication, authorization, invalid object path, validation, target-state conflict, and operational task failure. Retrying every error can make the situation worse. An authorization error will not become valid after ten retries, and a validation error should be fixed rather than hammered repeatedly.
Use bounded retries only for transient conditions such as network interruption or a known temporary task state, and include backoff. Permanent configuration errors should fail visibly and preserve enough response detail for an administrator to diagnose them.
Change automation should respect workspace and install governance
An API job can be technically correct and still violate the team’s change process. If workspace mode, package locking, peer review, or maintenance windows are part of FortiManager operations, automation should integrate with those controls rather than bypass them.
Separate preparation from deployment where practical. One job can create or update central objects, another can validate and generate a preview, and a controlled deployment step can perform installation after approval. This structure mirrors the difference between automation and orchestration: individual automated actions become safer when coordinated as an explicit workflow.
Use dedicated service accounts for different workflows and give each only the permissions it needs. A reporting script rarely needs write access. A package-install job may need execute privileges but not broad global administration.
Build automation around operational outcomes
Useful FortiManager automation includes inventory collection, compliance checks, object creation, device onboarding, retrieving package installation targets, controlled policy updates, and integration with ticketing or CI systems. The goal is to reduce repetitive work while preserving FortiManager as the authoritative management layer.
Start with read-only tasks because they expose the object model without configuration risk. Then automate small, well-understood writes in a lab. Add validation, logging, rollback or recovery procedures, and only then expand to operations that affect many FortiGates.
The strongest API workflow is boring in the best sense: it authenticates securely, checks current state, changes only what is intended, watches long-running tasks, handles errors explicitly, logs evidence, and exits cleanly. That is how JSON API access becomes reliable infrastructure rather than a faster way to make large mistakes.
Object paths should be treated as part of the automation contract. A request that is correct for the global database may be wrong inside an ADOM or policy package context. Build helper functions that construct paths from explicit inputs instead of scattering literal strings throughout scripts, and validate those paths with read operations before writes.
Bulk operations need careful batching. Sending hundreds of changes in one opaque transaction may be fast, but it can make error isolation difficult. Smaller batches with clear checkpoints allow the automation to stop after the first unexpected result and leave a comprehensible change trail.
A lab FortiManager should mirror production conventions closely enough to test permissions, ADOM paths, package structure, and version behavior. Mocking only the HTTP response is not sufficient for configuration automation because many failures come from product state rather than transport mechanics.
Finally, monitor automation as a service. Track authentication failures, task latency, API error rates, and the number of configuration changes per run. Sudden increases can indicate a schema change, credential problem, runaway loop, or unexpected environmental drift long before an administrator notices a bad configuration on a FortiGate.
Response data should be validated just as carefully as request data. Scripts should not assume a field is always present or that an empty list means success. Schema-aware parsing and defensive checks prevent a version change or partial response from turning into a destructive follow-up request.
Use request identifiers and structured logging so an API transaction can be traced across the client, FortiManager event logs, and background tasks. When automation fails after several steps, correlation IDs and object paths make it possible to reconstruct the exact sequence instead of relying on console output that may already be gone.
API clients should also distinguish discovery from enforcement. Inventory and compliance jobs can run frequently with read-only permissions, while write jobs can be scheduled or approval-gated. Separating these roles reduces the impact of a compromised credential and makes API logs easier to interpret because each service identity has a narrow, predictable purpose.