Enterprise APIs quickly make that model more complicated.

While building the v0.1.0 OSIRIS JSON Producer for HPE Aruba Networking Central, we had to account for different pagination models, inconsistent response envelopes, stack-specific query behavior, more than one authentication flow and probably found a bug in the Aruba Central API access point endpoint for which a discussion was opened.

The goal was not merely to export inventory. OSIRIS JSON intention is to translate Aruba Central data into a deterministic, vendor-neutral OSIRIS JSON document without silently dropping resources or losing the relationships that make the topology and the documentation useful.

Here are four implementation challenges that shaped the producer.

1. Pagination is an endpoint-level concern

A reusable API client often begins with the assumption that one pagination strategy will work across the service. That was not the case here.

Many Aruba Central endpoints accept limit-and-offset pagination and can return up to 1000 items per request. Other endpoints behave differently. For example, /gateways/{serial}/vlans uses cursor pagination, some enforces lower maximum page size, and returns a 400 response when a larger limit is requested.

Treating pagination as a client-wide behavior would have created a dangerous failure mode: the OSIRIS JSON producer could appear to succeed while returning an incomplete infrastructure snapshot.

The OSIRIS JSON producer therefore selects the pagination strategy according to the resource being collected. The important design principle was simple:

Pagination must be explicit, testable, and impossible to ignore.

For infrastructure discovery, partial success can be worse than a visible failure because downstream users may assume that the resulting topology is complete.

2. LLDP/CDP data needs tolerant parsing and strict identity rules

A topology becomes useful when it explains relationships, not only objects.

The Aruba Central /neighbours endpoint provides the LLDP/CDP adjacencies needed to connect switches, access points, gateways, and external devices. Its response shape, however, differs from the common {"items": [...]} envelope used by other endpoints. Depending on the response, the payload may arrive as a bare array or a flatter object.

We implemented a tolerant parser that accepts the observed shapes while still validating the data required to create an adjacency.

The endpoint also mixes entries such as Client and Stack records into the neighbor data. Those entities are already modeled elsewhere, so accepting every row would create duplicates and ambiguous relationships.

The producer filters those duplicate classes but deliberately preserves Unmanaged neighbors.

Aruba Central represents some of those external devices with synthetic serials in the form tpd_<hex>. By deriving the MAC address from that value, the producer can create an OSIRIS JSON stub resource for a third-party device found at the boundary of the managed Aruba domain.

That stub is valuable even when little else is known about the device. It records that the relationship exists and creates an identity that another producer may later enrich.

3. Switch stacks must be queried through the conductor

Switch stacks introduced a different class of problem.

When hardware details or interfaces are requested from a non-conductor member, Aruba Central can return 404. The conductor is the valid query target, and its response can include data for every physical member of the stack.

The collection flow therefore had to change from a device-by-device pattern to a stack-aware pattern:

1. identify the conductor;

2. query the stack through that device;

3. receive the combined response once; and

4. route each interface back to the correct in-memory switch by serial number.

This avoided redundant calls and prevented the interfaces of individual members from being assigned to the stack as a single undifferentiated object.

The broader lesson is that API resources do not always map one-to-one to real infrastructure resources. A collector has to understand the operational model behind the endpoint.

4. Authentication must support enterprise and self-service workflows

The producer supports standard OAuth 2.0 API Gateway credentials as well as HPE GreenLake Personal API clients.

For the GreenLake flow, the producer requests access tokens with grant_type=client_credentials against the GreenLake SSO endpoint. It also handles token renewal after a 401 response so that longer collection runs do not fail simply because a token expired.

Supporting both methods matters for adoption.

An enterprise team may provision a centrally governed application credential for scheduled CI/CD execution. An individual engineer evaluating the producer may need a lower-friction way to run it against an authorized test environment. The collection logic should remain identical regardless of how the token was obtained.

The resulting architecture

The result is a concurrent, read-only Go producer that converts Aruba Central resources and relationships into a deterministic OSIRIS JSON snapshot.

The producer currently models:

• switches, access points, gateways, and wired and wireless clients;

• switch stacks, VSX peers, LAGs, VLANs, and IAP mesh swarms;

• LLDP/CDP adjacencies, including stubs for unmanaged boundary devices;

• configuration-health and site-health context; and

• both concise documentation and deeper audit outputs.

The generated document remains local unless the operator chooses to send it elsewhere. It can be versioned, diffed, transformed into diagrams, integrated with CMDB/IPAM/DCIM workflows, or used as governed context for internal automation and AI platform/agents and MCP servers use-cases.

Download and try it: OSIRIS JSON Producer for HPE Aruba Networking Central

Feedback is especially welcome on identity reconciliation, VSX and stack modeling, unmanaged-neighbor handling, and other Aruba Central API edge cases encountered in production environments.