Book a demo

API reference

Devices

Infrastructure devices (routers, APs, backhaul radios, switches): detail, live health and config history

List devices

GET /v1/devices Try it

Your infrastructure devices: routers, access points, backhaul radios, switches and so on (customer radios are in list_cpes). Filter by site, region, the pingbox they're pinged from, device class or hardware type, or search names and IP addresses with q. get_device has a device's interfaces, addresses and live health.

Parameters

  • isp string query

    ISP code from GET /isps. Optional when the key reaches exactly one ISP.

  • site integer or string query

    Restrict to one site: site_id or site code from list_sites

  • region integer query

    Restrict to sites in this region: region_id from list_regions

  • pingbox integer query

    Restrict to devices pinged from this pingbox: a pingboxid from list_pingboxes

  • device_class string query

    Exact device class, e.g. Router, AP, Switch

  • hardware_type string query

    A hardware_type id, e.g. mikrotik, ubiquiti, cambium, snmp

  • q string query

    Substring match on device name or IP address

  • limit integer query

    Max rows (default 200, max 500)

  • cursor string query

    next_cursor from the previous page

Response

Also available as CSV: add format=csv. Columns follow the field order below, with nested fields as dotted columns (ap.name).

Paged: pass next_cursor back as cursor for the next page.

  • count integer
  • next_cursor string nullable

    Pass as cursor to get the next page; null on the last page

  • devices array of objects
    Each item: 9 fields
    • infid integer
    • name string
    • device_class string

      e.g. Router, AP, Switch, Backhaul AP

    • hardware_type object nullable

      The kind of device, which decides how Swift Fox collects from it

      2 fields
      • id string

        e.g. mikrotik, ubiquiti, cambium, snmp (any standard-SNMP device), generic

      • name string

        As the app shows it

    • model string nullable
    • ip string nullable

      Management IPv4 address

    • site object nullable

      The site

      3 fields
      • site_id integer
      • code string

        The ISP's short site code

      • name string
    • pingbox object

      The pingbox this device is pinged from (list_pingboxes)

      2 fields
      • pingboxid integer
      • name string
    • parent object nullable

      The device it hangs off in the network map

      2 fields
      • infid integer
      • name string

Example

curl -H "Authorization: Bearer $SWIFTFOX_KEY" \
  "https://api.swiftfox.net/v1/devices?isp=yourisp"

Response (example data):

{
  "count": 3,
  "next_cursor": "eyJ2IjoxLCJvIjozfQ",
  "devices": [
    {
      "infid": 101,
      "name": "Core Router",
      "device_class": "Router",
      "hardware_type": {
        "id": "mikrotik",
        "name": "Mikrotik"
      },
      "model": "CCR2116-12G-4S+",
      "ip": "10.10.0.1",
      "site": {
        "site_id": 3,
        "code": "RB-CORE",
        "name": "Riverbend Data Centre"
      },
      "pingbox": {
        "pingboxid": 0,
        "name": "Riverbend Cloud"
      },
      "parent": null
    },
    {
      "infid": 214,
      "name": "Hilltop Router",
      "device_class": "Router",
      "hardware_type": {
        "id": "mikrotik",
        "name": "Mikrotik"
      },
      "model": "CCR2004-16G-2S+",
      "ip": "10.10.7.1",
      "site": {
        "site_id": 7,
        "code": "HT",
        "name": "Hilltop Tower"
      },
      "pingbox": {
        "pingboxid": 1,
        "name": "Hilltop"
      },
      "parent": {
        "infid": 101,
        "name": "Core Router"
      }
    },
    {
      "infid": 230,
      "name": "Hilltop Sector 1",
      "device_class": "AP",
      "hardware_type": {
        "id": "cambium",
        "name": "Cambium"
      },
      "model": "ePMP 4500",
      "ip": "10.10.7.21",
      "site": {
        "site_id": 7,
        "code": "HT",
        "name": "Hilltop Tower"
      },
      "pingbox": {
        "pingboxid": 1,
        "name": "Hilltop"
      },
      "parent": {
        "infid": 214,
        "name": "Hilltop Router"
      }
    }
  ]
}

Get a device

GET /v1/devices/{infid} Try it

Everything about one infrastructure device: what and where it is, its parent device, its interfaces and IP addresses, and its live health. Health has an entry for each metric the device reports, with the latest value, its threshold state and severity, and any open issue. A metric with several values on one device, like signal per radio chain, repeats with a sub naming each one. Entries with has_history have history in get_device_history (series = the metric name), and each interface's traffic is in get_interface_traffic. value_ttl_seconds is how long until a value counts as stale (-1 means it doesn't expire). Interface names that carry a subscriber's login (PPPoE and similar) and staff comments need the pii scope. An issue's status is active (alerting now), pending (alerting, but still inside its grace period, so not alert-worthy yet) or recovering (back to good, but held open a while in case it comes back: recovered_at is when it went good, and resolves_at is when it clears if it stays good).

Parameters

  • infid integer path required

    Device infrastructure id from list_devices / list_backhauls

  • isp string query

    ISP code from GET /isps. Optional when the key reaches exactly one ISP.

Response

  • infid integer
  • name string
  • device_class string

    e.g. Router, AP, Switch, Backhaul AP

  • hardware_type object nullable

    The kind of device, which decides how Swift Fox collects from it

    2 fields
    • id string

      e.g. mikrotik, ubiquiti, cambium, snmp (any standard-SNMP device), generic

    • name string

      As the app shows it

  • model string nullable
  • ip string nullable

    Management IPv4 address

  • site object nullable

    The site

    3 fields
    • site_id integer
    • code string

      The ISP's short site code

    • name string
  • pingbox object

    The pingbox this device is pinged from (list_pingboxes)

    2 fields
    • pingboxid integer
    • name string
  • firmware string nullable
  • parent object nullable

    The device it hangs off in the network map

    2 fields
    • infid integer
    • name string
  • main_ip_interface_label string nullable

    User-entered label for the interface holding the main IP; often stale

  • interfaces array of objects
    Each item: 5 fields
    • name string

      Pass as interface for its traffic history (REST: /devices/{infid}/traffic?interface=<name>)

    • type string nullable
    • mac string nullable
    • comment string nullable
    • last_seen date-time nullable
  • local_ips array of objects
    Each item: 3 fields
    • ip string
    • interface string nullable
    • comment string nullable
  • health array of objects
    Each item: 10 fields
    • metric string
    • sub string optional

      Which value of a metric with several on one entity (a radio chain, a vulnerability)

    • description string optional
    • value number nullable

      Latest collected value

    • unit string optional
    • state string

      Threshold state name for the value, e.g. Good, Warning, Down; Inactive = the metric has no thresholds set

    • severity one of: "ok", "info", "warning", "outage", "critical" nullable

      ok, info, warning, outage or critical for the state's level; null when the metric has no thresholds

    • value_ttl_seconds integer nullable

      Seconds until the value is considered stale; -1 = no expiry set

    • issue object nullable
      6 fields
      • details string
      • severity one of: "ok", "info", "warning", "outage", "critical"

        ok while recovering, otherwise info, warning, outage or critical

      • since date-time nullable

        When the issue started

      • status one of: "active", "pending", "recovering"
      • recovered_at date-time nullable

        recovering only: when the metric went back to good

      • resolves_at date-time nullable

        recovering only: when the issue clears if it stays good

    • has_history boolean optional

      Devices: true when the metric's history is available (REST: /devices/{infid}/history/{metric})

Example

curl -H "Authorization: Bearer $SWIFTFOX_KEY" \
  "https://api.swiftfox.net/v1/devices/1234?isp=yourisp"

Response (example data):

{
  "infid": 230,
  "name": "Hilltop Sector 1",
  "device_class": "AP",
  "hardware_type": {
    "id": "cambium",
    "name": "Cambium"
  },
  "model": "ePMP 4500",
  "ip": "10.10.7.21",
  "site": {
    "site_id": 7,
    "code": "HT",
    "name": "Hilltop Tower"
  },
  "pingbox": {
    "pingboxid": 1,
    "name": "Hilltop"
  },
  "firmware": "5.10.2",
  "parent": {
    "infid": 214,
    "name": "Hilltop Router"
  },
  "main_ip_interface_label": null,
  "interfaces": [
    {
      "name": "eth0",
      "type": "ethernetCsmacd",
      "mac": "00:00:5E:00:53:21",
      "comment": null,
      "last_seen": "2026-10-08T22:08:07Z"
    }
  ],
  "local_ips": [
    {
      "ip": "10.10.7.21",
      "interface": "br0",
      "comment": null
    }
  ],
  "health": [
    {
      "metric": "Health:CPU Usage",
      "description": "CPU percentage used as reported by the device",
      "value": 23,
      "unit": "%",
      "state": "Good",
      "severity": "ok",
      "value_ttl_seconds": 604790,
      "issue": null,
      "has_history": true
    },
    {
      "metric": "Health:Temperature",
      "description": "Device temperature is outside threshold",
      "value": 71,
      "unit": "deg C",
      "state": "Warning",
      "severity": "warning",
      "value_ttl_seconds": 604790,
      "issue": {
        "details": "Warning - 71 deg C",
        "severity": "warning",
        "since": "2026-10-08T21:40:12Z",
        "status": "active",
        "recovered_at": null,
        "resolves_at": null
      },
      "has_history": true
    },
    {
      "metric": "Wireless:Signal",
      "sub": "Chain 0",
      "description": "Receive Signal Strength (RSSI) in dBm",
      "value": -58,
      "unit": "dBm",
      "state": "Good",
      "severity": "ok",
      "value_ttl_seconds": 604790,
      "issue": null,
      "has_history": false
    },
    {
      "metric": "Ping:Quality",
      "description": "A weighted quality rating based on packet loss and latency. 1 = Down/Black … 6 = Bright Green.",
      "value": 6,
      "unit": "",
      "state": "Good",
      "severity": "ok",
      "value_ttl_seconds": 604800,
      "issue": null,
      "has_history": false
    }
  ]
}

List config changes

GET /v1/devices/{infid}/configs Try it

When a device's config changed, newest first. Pass a revision to get_config for that config, or two of them to diff_configs to see what changed. A backup is only stored when the config changes, so a revision's time is when the config changed. last_collected_at is when the config was last read, changed or not: if it's recent, an old newest revision just means a stable config; if it's old, collection is failing, and the device's Task:Connection issue usually says why.

Parameters

  • infid integer path required

    Device infrastructure id

  • isp string query

    ISP code from GET /isps. Optional when the key reaches exactly one ISP.

  • limit integer query

    Max entries (default 50, max 500)

  • cursor string query

    next_cursor from the previous page

Response

Also available as CSV: add format=csv. Columns follow the field order below, with nested fields as dotted columns (ap.name).

Paged: pass next_cursor back as cursor for the next page.

  • infid integer
  • last_collected_at date-time nullable

    When the config was last read successfully, whether or not it changed; null if no successful read is recorded

  • count integer
  • next_cursor string nullable

    Pass as cursor to get the next page; null on the last page

  • changes array of objects

    Newest first

    Each item: 5 fields
    • revision integer

      The revision's id (unix seconds): pass it to get_config or diff_configs

    • changed_at date-time
    • format string

      The config's syntax: mikrotik (a RouterOS export), ubiquiti or cambium

    • size_bytes integer
    • content_hash string

Example

curl -H "Authorization: Bearer $SWIFTFOX_KEY" \
  "https://api.swiftfox.net/v1/devices/1234/configs?isp=yourisp"

Response (example data):

{
  "infid": 101,
  "last_collected_at": "2026-10-08T22:00:12Z",
  "count": 2,
  "next_cursor": null,
  "changes": [
    {
      "revision": 1791468760,
      "changed_at": "2026-10-08T14:12:40Z",
      "format": "mikrotik",
      "size_bytes": 18214,
      "content_hash": "3f1c2a9e6b0d47c8a5e2f19b7d6c4a0e8b5f3d21"
    },
    {
      "revision": 1789981391,
      "changed_at": "2026-09-21T09:03:11Z",
      "format": "mikrotik",
      "size_bytes": 18166,
      "content_hash": "9a0e4b1c7d2f5e8a3b6c9d0e1f2a3b4c5d6e7f80"
    }
  ]
}

Get a device's health

GET /v1/devices/{infid}/health Try it

The live monitored metrics for one device, backhaul or CPE: each metric's latest value and unit, its threshold state and severity, and any open issue. It's the same list as get_device's health, for backhauls and CPEs too. For devices, entries with has_history have history in get_device_history (series = the metric name). An issue's status is active (alerting now), pending (alerting, but still inside its grace period, so not alert-worthy yet) or recovering (back to good, but held open a while in case it comes back: recovered_at is when it went good, and resolves_at is when it clears if it stays good).

Parameters

  • infid integer path required

    infid / bhid / cpeid

  • isp string query

    ISP code from GET /isps. Optional when the key reaches exactly one ISP.

Response

Also available as CSV: add format=csv. Columns follow the field order below, with nested fields as dotted columns (ap.name).

  • type string

    device, backhaul or cpe; more types may be added

  • id integer
  • metrics array of objects
    Each item: 10 fields
    • metric string
    • sub string optional

      Which value of a metric with several on one entity (a radio chain, a vulnerability)

    • description string optional
    • value number nullable

      Latest collected value

    • unit string optional
    • state string

      Threshold state name for the value, e.g. Good, Warning, Down; Inactive = the metric has no thresholds set

    • severity one of: "ok", "info", "warning", "outage", "critical" nullable

      ok, info, warning, outage or critical for the state's level; null when the metric has no thresholds

    • value_ttl_seconds integer nullable

      Seconds until the value is considered stale; -1 = no expiry set

    • issue object nullable
      6 fields
      • details string
      • severity one of: "ok", "info", "warning", "outage", "critical"

        ok while recovering, otherwise info, warning, outage or critical

      • since date-time nullable

        When the issue started

      • status one of: "active", "pending", "recovering"
      • recovered_at date-time nullable

        recovering only: when the metric went back to good

      • resolves_at date-time nullable

        recovering only: when the issue clears if it stays good

    • has_history boolean optional

      Devices: true when the metric's history is available (REST: /devices/{infid}/history/{metric})

Example

curl -H "Authorization: Bearer $SWIFTFOX_KEY" \
  "https://api.swiftfox.net/v1/devices/1234/health?isp=yourisp"

Response (example data):

{
  "type": "device",
  "id": 230,
  "metrics": [
    {
      "metric": "Health:CPU Usage",
      "description": "CPU percentage used as reported by the device",
      "value": 23,
      "unit": "%",
      "state": "Good",
      "severity": "ok",
      "value_ttl_seconds": 604790,
      "issue": null,
      "has_history": true
    },
    {
      "metric": "Health:Temperature",
      "description": "Device temperature is outside threshold",
      "value": 71,
      "unit": "deg C",
      "state": "Warning",
      "severity": "warning",
      "value_ttl_seconds": 604790,
      "issue": {
        "details": "Warning - 71 deg C",
        "severity": "warning",
        "since": "2026-10-08T21:40:12Z",
        "status": "active",
        "recovered_at": null,
        "resolves_at": null
      },
      "has_history": true
    },
    {
      "metric": "Wireless:Signal",
      "sub": "Chain 0",
      "description": "Receive Signal Strength (RSSI) in dBm",
      "value": -58,
      "unit": "dBm",
      "state": "Good",
      "severity": "ok",
      "value_ttl_seconds": 604790,
      "issue": null,
      "has_history": false
    },
    {
      "metric": "Ping:Quality",
      "description": "A weighted quality rating based on packet loss and latency. 1 = Down/Black … 6 = Bright Green.",
      "value": 6,
      "unit": "",
      "state": "Good",
      "severity": "ok",
      "value_ttl_seconds": 604800,
      "issue": null,
      "has_history": false
    }
  ]
}

Get an interface's traffic

GET /v1/devices/{infid}/traffic Try it

History for one device, backhaul or CPE, rolled up into time buckets (up to 200, or max_points up to 500), so long ranges stay small. Series: devices have pings, quality, signal, traffic (with interface), or a health metric name from get_device whose has_history is true; backhauls have pings, quality, traffic or capacity; CPEs have pings, traffic, plan, quality or signal. Each point has its bucket's start time (at), the values for the series and how many readings went into it (samples). pings: loss_avg_pct, loss_max_pct, latency_avg_ms, latency_min_ms, latency_max_ms. traffic, capacity and plan: avg and max Mbps per direction (an interface's in/out, a backhaul's ap_to_su/su_to_ap, a CPE's down/up). quality: quality_avg, quality_min (0 down to 6 perfect). signal: one point per radio chain per bucket. Health metrics: value_avg, value_min, value_max in unit. A missing bucket means nothing was recorded then.

Parameters

  • infid integer path required

    The infid, bhid or cpeid

  • isp string query

    ISP code from GET /isps. Optional when the key reaches exactly one ISP.

  • interface string query

    Device traffic only: the interface name, as get_device lists it

  • period one of: "1hour", "4hours", "day", "week", "month", "year" query

    Lookback from now (default day). Use from/to instead for a past window

  • from integer or string query

    Range start: unix seconds or 'YYYY-MM-DD HH:MM:SS' UTC

  • to integer or string query

    Range end (default: now)

  • max_points integer query

    Point budget (default 200, max 500); buckets are sized to stay under it

Response

Also available as CSV: add format=csv. Columns follow the field order below, with nested fields as dotted columns (ap.name).

  • type string

    device, backhaul or cpe; more types may be added

  • id integer
  • series string
  • interface string optional

    Device traffic: the interface

  • source string optional

    Backhaul capacity: the measurement shown

  • unit string nullable

    Health metrics: the value's unit. Other series carry the unit in their field names

  • from date-time
  • to date-time
  • bucket_seconds integer
  • point_count integer
  • points array of objects
    Each item: 2 fields
    • at date-time

      Bucket start

    • chain string optional

      signal only: the radio chain

Example

curl -H "Authorization: Bearer $SWIFTFOX_KEY" \
  "https://api.swiftfox.net/v1/devices/1234/traffic?isp=yourisp"

Response (example data):

{
  "type": "device",
  "id": 101,
  "series": "traffic",
  "interface": "sfp1-HT",
  "unit": null,
  "from": "2026-10-08T21:00:00Z",
  "to": "2026-10-08T22:00:00Z",
  "bucket_seconds": 1800,
  "point_count": 2,
  "points": [
    {
      "at": "2026-10-08T21:00:00Z",
      "in_avg_mbps": 41.2,
      "in_max_mbps": 63.5,
      "out_avg_mbps": 498.1,
      "out_max_mbps": 571.3,
      "samples": 30
    },
    {
      "at": "2026-10-08T21:30:00Z",
      "in_avg_mbps": 38.7,
      "in_max_mbps": 55,
      "out_avg_mbps": 526.4,
      "out_max_mbps": 589.9,
      "samples": 30
    }
  ]
}

Get a config revision

GET /v1/devices/{infid}/configs/{revision} Try it

A device's config backup as text: the newest revision, or a particular one if you pass revision (from list_config_changes). To see what changed between two revisions, diff_configs is quicker than fetching both. Backups can contain passwords and keys, so this needs the network_viewconfigs permission. A backup is only stored when the config changes, so a revision's time is when the config changed. last_collected_at is when the config was last read, changed or not: if it's recent, an old newest revision just means a stable config; if it's old, collection is failing, and the device's Task:Connection issue usually says why.

Parameters

  • infid integer path required

    Device infrastructure id

  • revision integer or string path required

    A revision from list_config_changes (unix seconds; 'YYYY-MM-DD HH:MM:SS' UTC also works)

  • isp string query

    ISP code from GET /isps. Optional when the key reaches exactly one ISP.

Response

  • infid integer
  • revision integer

    The revision's id (unix seconds): pass it to get_config or diff_configs

  • changed_at date-time
  • format string

    The config's syntax: mikrotik (a RouterOS export), ubiquiti or cambium

  • size_bytes integer
  • content_hash string
  • last_collected_at date-time nullable

    When the config was last read successfully, whether or not it changed; null if no successful read is recorded

  • config_text string

Example

curl -H "Authorization: Bearer $SWIFTFOX_KEY" \
  "https://api.swiftfox.net/v1/devices/1234/configs/revision?isp=yourisp"

Response (example data):

{
  "infid": 101,
  "revision": 1791468760,
  "changed_at": "2026-10-08T14:12:40Z",
  "format": "mikrotik",
  "size_bytes": 18214,
  "content_hash": "3f1c2a9e6b0d47c8a5e2f19b7d6c4a0e8b5f3d21",
  "last_collected_at": "2026-10-08T22:00:12Z",
  "config_text": "# 2026-10-08 14:12:40 by RouterOS 7.20.1\n/interface bridge\nadd name=bridge-lan\n/ip address\nadd address=10.10.0.1/24 interface=bridge-lan\n…"
}

Diff two config revisions

GET /v1/devices/{infid}/configs/diff Try it

What changed between two config revisions of a device, as a unified diff: from is the older revision and to the newer one, both from list_config_changes. It's a good next step when list_config_changes or events_around shows a change near an incident. Like get_config, it needs the network_viewconfigs permission.

Parameters

  • infid integer path required

    Device infrastructure id

  • isp string query

    ISP code from GET /isps. Optional when the key reaches exactly one ISP.

  • from integer or string query required

    The older revision, from list_config_changes

  • to integer or string query required

    The newer revision

Response

  • infid integer
  • from object

    The older revision

    2 fields
    • revision integer
    • changed_at date-time
  • to object

    The newer revision

    2 fields
    • revision integer
    • changed_at date-time
  • lines_added integer
  • lines_removed integer
  • identical boolean
  • diff string

    Unified diff: lines starting - are only in from, + only in to, and a space are unchanged context

Example

curl -H "Authorization: Bearer $SWIFTFOX_KEY" \
  "https://api.swiftfox.net/v1/devices/1234/configs/diff?isp=yourisp&from=…&to=…"

Response (example data):

{
  "infid": 101,
  "from": {
    "revision": 1789981391,
    "changed_at": "2026-09-21T09:03:11Z"
  },
  "to": {
    "revision": 1791468760,
    "changed_at": "2026-10-08T14:12:40Z"
  },
  "lines_added": 1,
  "lines_removed": 1,
  "identical": false,
  "diff": "@@ old line ~212, new line ~212 @@\n /ip service\n-set ssh address=10.0.0.0/8\n+set ssh address=10.0.0.0/8,10.99.0.0/24\n set telnet disabled=yes\n"
}

Get the latest config

GET /v1/devices/{infid}/configs/latest Try it

A device's config backup as text: the newest revision, or a particular one if you pass revision (from list_config_changes). To see what changed between two revisions, diff_configs is quicker than fetching both. Backups can contain passwords and keys, so this needs the network_viewconfigs permission. A backup is only stored when the config changes, so a revision's time is when the config changed. last_collected_at is when the config was last read, changed or not: if it's recent, an old newest revision just means a stable config; if it's old, collection is failing, and the device's Task:Connection issue usually says why.

Parameters

  • infid integer path required

    Device infrastructure id

  • isp string query

    ISP code from GET /isps. Optional when the key reaches exactly one ISP.

Response

  • infid integer
  • revision integer

    The revision's id (unix seconds): pass it to get_config or diff_configs

  • changed_at date-time
  • format string

    The config's syntax: mikrotik (a RouterOS export), ubiquiti or cambium

  • size_bytes integer
  • content_hash string
  • last_collected_at date-time nullable

    When the config was last read successfully, whether or not it changed; null if no successful read is recorded

  • config_text string

Example

curl -H "Authorization: Bearer $SWIFTFOX_KEY" \
  "https://api.swiftfox.net/v1/devices/1234/configs/latest?isp=yourisp"

Response (example data):

{
  "infid": 101,
  "revision": 1791468760,
  "changed_at": "2026-10-08T14:12:40Z",
  "format": "mikrotik",
  "size_bytes": 18214,
  "content_hash": "3f1c2a9e6b0d47c8a5e2f19b7d6c4a0e8b5f3d21",
  "last_collected_at": "2026-10-08T22:00:12Z",
  "config_text": "# 2026-10-08 14:12:40 by RouterOS 7.20.1\n/interface bridge\nadd name=bridge-lan\n/ip address\nadd address=10.10.0.1/24 interface=bridge-lan\n…"
}

Get a device's history

GET /v1/devices/{infid}/history/{series} Try it

History for one device, backhaul or CPE, rolled up into time buckets (up to 200, or max_points up to 500), so long ranges stay small. Series: devices have pings, quality, signal, traffic (with interface), or a health metric name from get_device whose has_history is true; backhauls have pings, quality, traffic or capacity; CPEs have pings, traffic, plan, quality or signal. Each point has its bucket's start time (at), the values for the series and how many readings went into it (samples). pings: loss_avg_pct, loss_max_pct, latency_avg_ms, latency_min_ms, latency_max_ms. traffic, capacity and plan: avg and max Mbps per direction (an interface's in/out, a backhaul's ap_to_su/su_to_ap, a CPE's down/up). quality: quality_avg, quality_min (0 down to 6 perfect). signal: one point per radio chain per bucket. Health metrics: value_avg, value_min, value_max in unit. A missing bucket means nothing was recorded then.

Parameters

  • infid integer path required

    The infid, bhid or cpeid

  • series string path required

    Which history; see the operation's description

  • isp string query

    ISP code from GET /isps. Optional when the key reaches exactly one ISP.

  • period one of: "1hour", "4hours", "day", "week", "month", "year" query

    Lookback from now (default day). Use from/to instead for a past window

  • from integer or string query

    Range start: unix seconds or 'YYYY-MM-DD HH:MM:SS' UTC

  • to integer or string query

    Range end (default: now)

  • max_points integer query

    Point budget (default 200, max 500); buckets are sized to stay under it

Response

Also available as CSV: add format=csv. Columns follow the field order below, with nested fields as dotted columns (ap.name).

  • type string

    device, backhaul or cpe; more types may be added

  • id integer
  • series string
  • interface string optional

    Device traffic: the interface

  • source string optional

    Backhaul capacity: the measurement shown

  • unit string nullable

    Health metrics: the value's unit. Other series carry the unit in their field names

  • from date-time
  • to date-time
  • bucket_seconds integer
  • point_count integer
  • points array of objects
    Each item: 2 fields
    • at date-time

      Bucket start

    • chain string optional

      signal only: the radio chain

Example

curl -H "Authorization: Bearer $SWIFTFOX_KEY" \
  "https://api.swiftfox.net/v1/devices/1234/history/series?isp=yourisp"

Response (example data):

{
  "type": "device",
  "id": 230,
  "series": "Health:Temperature",
  "unit": "deg C",
  "from": "2026-10-08T21:00:00Z",
  "to": "2026-10-08T22:00:00Z",
  "bucket_seconds": 1800,
  "point_count": 2,
  "points": [
    {
      "at": "2026-10-08T21:00:00Z",
      "value_avg": 68.4,
      "value_min": 67,
      "value_max": 70,
      "samples": 30
    },
    {
      "at": "2026-10-08T21:30:00Z",
      "value_avg": 70.6,
      "value_min": 69,
      "value_max": 72,
      "samples": 30
    }
  ]
}

Collect a config now

POST /v1/devices/{infid}/config-collections Try it

Collect a device's config backup now instead of waiting for its turn. It tells you whether the config changed: backups are only stored when it does, so collected with no change is the normal, healthy result. Works for MikroTik, Ubiquiti and Cambium devices, and needs the edit_inf permission.

Needs the actions scope.

Parameters

  • infid integer path required

    Device infrastructure id

  • isp string query

    ISP code from GET /isps. Optional when the key reaches exactly one ISP.

Response

  • device object

    The device

    2 fields
    • infid integer
    • name string
  • collected boolean

    false when the device answered but returned no config

  • config_changed boolean
  • latest_revision object nullable

    The newest stored revision, for get_config or diff_configs

    2 fields
    • revision integer
    • changed_at date-time
  • last_collected_at date-time nullable

    When the config was last read successfully, whether or not it changed

Example

curl -X POST -H "Authorization: Bearer $SWIFTFOX_KEY" \
  -H "Content-Type: application/json" -d '{}' \
  "https://api.swiftfox.net/v1/devices/1234/config-collections?isp=yourisp"

Response (example data):

{
  "device": {
    "infid": 101,
    "name": "Core Router"
  },
  "collected": true,
  "config_changed": false,
  "latest_revision": {
    "revision": 1791468760,
    "changed_at": "2026-10-08T14:12:40Z"
  },
  "last_collected_at": "2026-10-08T22:16:05Z"
}