Device APIs V2 (Performance Upgrade) — Changes & Migration Guide

We’ve enhanced the performance of two device-related API endpoints. We call these the V2 Device APIs. To simplify adoption, the APIs remain REST-ful with only minor changes.

V1 version of APIs continue to be available—migrating to V2 APIs is optional. Use this article to see what changed and how to migrate if you choose.

Scope

Applies only to:

• GET /inventory/device/info

  • V1 → Inventory - Device - Read Multiple Devices’ Info - V1

  • V2 → Inventory - Device - Read Multiple Devices’ Info - V2

• GET /inventory/device/info/{id}

  • V1 → Inventory - Device - Read a Single Device’s Info - V1

  • V2 → Inventory - Device - Read a Single Device’s Info - V2

V1 ↔ V2 diff (paths · params · schemas)

Paths & content type

Parameters — GET /device/info/{id} (single)

Response schema (both endpoints)

Migration Steps (do this in order)

1. Endpoint paths

   • Update to /v2/api/inventory/device/info and /v2/api/inventory/device/info/{id}.

2. Filters

   • Rename: filter[vendorName] → filter[make].

   • Remove: filter[modifiedAfter], filter[stateKnown].

   • Optional: adopt filter[model], filter[manageStatus].

   • Recreate “modified since” client-side (keep a watermark and locally filter on a stable timestamp field you trust).

3. Tenant scoping

   • Replace tenants (plural) with tenant (singular).

   • If you previously queried multiple tenants in one call, fan-out per tenant and merge results (mind rate limits). Auvik’s recommendation is to fetch from a parent tenant to get all the children, but if you needed a curated set of tenants then fan out per tenant.

4. Includes / sparse fieldsets

   • Remove include and fields[deviceDetail] from all requests (multi and single).

   • If you still need those details, plan follow-up calls per device and join client-side.

5. Pagination behavior

   • Adjust for larger defaults: page[first] / page[last] now 1000 (was 100).

   • Revisit batching/loops to prevent memory spikes.

6. Response field mapping

   • Map vendorName → make.

   • Handle removed fields: lastModified, discoveryStatus, trafficInsightsStatus.

   • Start using: make, model, deviceTypeDescription.

7. Relationships & side-loads

   • Remove logic expecting data[].relationships.deviceDetail or top-level included.

   • Fetch needed details via dedicated endpoints and join in your app.

8. Client contracts & tests

   • Keep Accept: application/vnd.api+json.

   • Update request builders (paths/params), response DTOs, and BI mappings (e.g., vendor → make).

   • Add tests covering: filter rename, single-tenant fan-out, absence of include/fields, bigger page defaults, removed attributes, missing deviceDetail.

Quick request examples

V1 (multi)

GET /v1/inventory/device/info?filter[vendorName]=Cisco&tenants=123,456&include=deviceDetail Accept: application/vnd.api+json 

V2 (multi)

GET /v2/api/inventory/device/info?filter[make]=Cisco&tenant=123 Accept: application/vnd.api+json GET /v2/api/inventory/device/info?filter[make]=Cisco&tenant=456 Accept: application/vnd.api+json 

Merge the two result sets client-side; there’s no side-loading in V2.

For more information, check out the Device APIs v2 FAQ.