One read-only API user on the firewall turns a ping-only FortiGate into a fully observed one — identity, health, VPN tunnels, the policy rule base, configuration backups and firmware advisories — next to the rest of the network, with tickets in the IT Service Management (ITSM) system your team already uses.
/api/v2/monitor and /api/v2/cmdb) on the HTTPS admin port, with an API token or an admin login.A FortiGate watched by ping alone says up or down and nothing else. FortiOS has a REST API that answers what a NOC actually asks, and SmartTile only ever reads it: every monitoring call is a GET, and the one write SmartTile can make — starting a firmware upgrade — is switched off platform-wide by default. Up/down stays with SmartTile’s ping check; the API adds everything behind it.
Serial, model, hostname, FortiOS version and MAC are written to the device record every 5 minutes, each marked “FortiGate API” with the time. A value typed by a person is never overwritten.
CPU, memory and session count with the FortiGate’s own recent history, interface link state and uptime — in the device’s Analytics view and in Device Health.
Every IPsec tunnel: up or down, phase-2 selectors, local and remote subnets, bytes in and out — plus the count of active SSL-VPN sessions. Read live when the VPN view is opened.
Every rule and the addresses, groups, services and VIPs it references, with per-rule hit counters. Re-read hourly; every rule added, removed or modified is logged field by field (90-day view).
The full configuration pulled over HTTPS on the device’s backup schedule. Saved only when it changes, with a diff of what changed; a change can raise a ticket. Needs super_admin — see the table.
FortiGuard builds compared with what is running. Target = newest patch on the same branch (7.4.4 → 7.4.8); a branch jump is flagged as a planned migration. Ticketed with a 14-day SLA, scheduled, verified, closed.
The Uptime view uses the FortiGate’s boot counter and the outages SmartTile recorded — a recorded DOWN always counts, and the view never guesses 100% from silence.
Tests what is typed, before saving. A timeout becomes a sentence: wrong port (and which one answers), HTTPS admin closed on the WAN, or token rejected.
10443 if left blank).157.245.117.9 and 159.203.150.140.| Access level | What works |
|---|---|
| Read-only API user or admin | Identity, health, VPN tunnels, policy inventory and change ledger, firmware advisories (detect, ticket, schedule, verify). |
| super_admin profile | Everything above, plus configuration backups over the API — FortiOS refuses the backup call to anyone less. Still reads only. |
| Firmware execution · off by default | SmartTile starts the scheduled upgrade itself. Needs the platform switch “Execute upgrades” on and stored credentials; the FortiGate reboots to finish. Otherwise a technician upgrades in the window and SmartTile verifies. |
Every monitoring, policy, backup and firmware-check call is a GET. SmartTile never writes a rule. The only write — the firmware upgrade — is off platform-wide by default.
Sent only in the Authorization header. The API returns “token set”, never the value; the field always reads blank; the audit log redacts it by field-name pattern.
With Trusted Hosts, only 157.245.117.9 and 159.203.150.140 can use that user on the admin port. Revoke the user and access ends.
Every FortiGate view is tenant-checked — your company’s users and SmartChoice super admins only. Each Test REST API run is written to the activity log with the result.
/api/v2/monitor/system/statusidentity, FortiOS version, uptime; the Test call/api/v2/monitor/system/resource/usageCPU, memory, sessions/api/v2/monitor/system/interfaceinterfaces, link state, MAC/api/v2/monitor/vpn/ipsec · /vpn/sslIPsec tunnels · SSL-VPN sessions/api/v2/cmdb/firewall/policythe rule base (inventory, ledger)/api/v2/monitor/firewall/policyper-rule hit counters/api/v2/cmdb/firewall/address · addrgrp · vipobjects the rules reference (+ services)/api/v2/monitor/system/config/backupconfiguration backup (super_admin)/api/v2/monitor/system/firmwarerunning and available builds; verify/api/v2/monitor/system/firmware/upgradeonly with “Execute upgrades” switched onOne advisory per FortiGate with running and target versions, the same-branch or branch-jump note and the SLA date — opened in Rev.io and in each system the company has enabled for firmware, Jira Service Management and Asana included.
Schedule the window; the ticket gets a note when it opens. SmartTile re-reads the running version for up to 4 hours afterwards and closes the ticket when it matches.
FirmwareAutomate is on for Automate-tier companies, with a per-device off switch. Auto-ticketing and contact e-mails each have their own switch; execution is off until you turn it on.
| Change | Risk | Rollback |
|---|---|---|
| Read-only API user and its token | Low — the profile cannot change configuration; SmartTile only reads. | Delete the API user. |
| Trusted-host entries for two SmartTile addresses | Low — narrows who may use the new user to two hosts. | Remove the entries. |
| Optional: super_admin profile for config backups | Medium — a full read of the configuration; still no writes. | Downgrade the profile; backups stop, the rest continues. |
| Optional: firmware execution by SmartTile | A planned change per window, with a reboot. | Leave “Execute upgrades” off — the default. |
| Objection | Answer |
|---|---|
| “You would have write access to our firewall.” | No. The profile is read-only and the calls are reads. Firmware execution is the only write, and it stays off unless it is switched on. |
| “Is the token safe with you?” | Never shown back, never logged, sent only as a header, usable only from the two addresses you allow. |
| “We already have FortiManager.” | Different job. SmartTile puts the FortiGate next to your circuits, switches and access points, with tickets in your ITSM system — it does not manage configuration. |