`MerakiClient` constructor omits organization Refit clients used by Dashboard API; `IOrganizationsWirelessDevicesChannelUtilization` fails Refit build

[pjorritsma]

Title

MerakiClient constructor omits organization Refit clients used by Dashboard API; IOrganizationsWirelessDevicesChannelUtilization fails Refit build

---

Body

Environment

• Package: Meraki.Api 1.70.5
• Target: .NET 9.0
• Consumer: internal DataHub sync service (Cisco Meraki Dashboard API v1)

Summary

Several organization-level API clients that exist in the SDK surface area are never assigned in the MerakiClient constructor. They remain null after new MerakiClient(...), which causes NullReferenceException when calling methods such as GetOrganizationSummarySwitchPowerHistoryAsync.

Additionally, IOrganizationsWirelessDevicesChannelUtilization cannot be instantiated via the library’s own RefitFor<T>() helper because of a Refit route/parameter name mismatch.

Expected behavior

After constructing MerakiClient with valid options, all public section properties that expose Refit interfaces should be initialized the same way as Organizations.Summary.Top, Organizations.SwitchPortsOverview, and Organizations.Uplinks.

Actual behavior

On a fresh client (API key can be a dummy string — wiring happens in the ctor):

Path	Initialized?
Organizations.Summary.Top	Yes
Organizations.SwitchPortsOverview	Yes
Organizations.Summary.SwitchPower	No (null)
Organizations.Appliance.Uplinks.Usage	No (null)
Organizations.Wireless.Devices.Latency	No (null)
Organizations.Wireless.Devices.PacketLoss	No (null)
Organizations.Wireless.Devices.ChannelUtilization	No (null)

Organizations.Appliance and Organizations.Wireless sections are never populated in the constructor’s Organizations = new OrganizationsSection { ... } initializer (only Summary.Top is set under Summary).

Minimal reproduction

using Meraki.Api;

var client = new MerakiClient(new MerakiClientOptions
{
    ApiKey = "0000000000000000000000000000000000000000",
    UserAgent = "Repro/1.0"
});

Console.WriteLine(client.Organizations.Summary.SwitchPower is null);           // True
Console.WriteLine(client.Organizations.Appliance.Uplinks.Usage is null);        // True
Console.WriteLine(client.Organizations.Wireless.Devices.Latency is null);     // True
Console.WriteLine(client.Organizations.Wireless.Devices.PacketLoss is null);  // True
Console.WriteLine(client.Organizations.Wireless.Devices.ChannelUtilization is null); // True

Calling any method on the null clients throws NullReferenceException, e.g.:

await client.Organizations.Summary.SwitchPower!
    .GetOrganizationSummarySwitchPowerHistoryAsync("123456", "2026-01-01T00:00:00Z", "2026-01-02T00:00:00Z");

Root cause (constructor)

In MerakiClient, organization summary is only partially wired:

Summary = new()
{
    Top = RefitFor(Organizations.Summary.Top)
    // SwitchPower is never assigned
},

There is no initializer block for Appliance = new() { Uplinks = new() { Usage = RefitFor(...) } } or Wireless = new() { Devices = new() { Latency = ..., PacketLoss = ... } } under OrganizationsSection.

Official API endpoints (for reference):

• Get organization summary switch power history
• Get organization appliance uplinks usage by network
• Get organization wireless devices latencies by device
• Get organization wireless devices packet loss by device
• Get organization wireless devices channel utilizations by device

Separate bug: IOrganizationsWirelessDevicesChannelUtilization

Even when creating the client via the library’s private RefitFor<T>() (same path as other endpoints), instantiation fails:

ArgumentException: URL /organizations/{organizationId}/wireless/devices/channelUtilization/byDevice
has parameter organizationid, but no method parameter matches

So the interface cannot be used at all in 1.70.5 until the Refit route template or method parameter names are aligned (likely organizationId vs organizationid).

Suggested fix

1. In MerakiClient constructor, extend the Organizations initializer, for example:

Appliance = new()
{
    Uplinks = new()
    {
        Usage = RefitFor(Organizations.Appliance.Uplinks.Usage)
    }
},
Wireless = new()
{
    Devices = new()
    {
        Latency = RefitFor(Organizations.Wireless.Devices.Latency),
        PacketLoss = RefitFor(Organizations.Wireless.Devices.PacketLoss),
        ChannelUtilization = RefitFor(Organizations.Wireless.Devices.ChannelUtilization),
    }
},
Summary = new()
{
    Top = RefitFor(Organizations.Summary.Top),
    SwitchPower = RefitFor(Organizations.Summary.SwitchPower),
},

2. Fix the Refit attribute/parameter naming on IOrganizationsWirelessDevicesChannelUtilization so RefitFor succeeds.

Consumer workaround (until fixed)

We currently call the private RefitFor<T>() via reflection for the four interfaces that can be created, and skip channel utilization sync with a log line. We would prefer to remove this once the package is fixed.

---

Optional labels (if available)

bug, MerakiClient, organizations

[pjorritsma]

Any comment?

[rolandbanks]

Thanks for the report, @pjorritsma. The repro and the root cause analysis both landed on it, which made this quick to confirm and fix.

Both defects are fixed in 1.70.45 (PR #358). Neither is deferred.

1. Constructor wiring

All five are now assigned in the MerakiClient constructor.

2. IOrganizationsWirelessDevicesChannelUtilization

Fixed. Your diagnosis was right in substance and slightly off in detail: it was not a casing mismatch but a letter transposition. All four methods declared the parameter as orgnanizationId while the routes used {organizationId}. Refit lowercases names when matching, which is why it surfaced as organizationid and looked like a casing problem.

The parameter is now organizationId throughout. That is technically a source-breaking rename, but since the interface could not be constructed at all before this fix, no working caller can exist.

You can drop the reflection-based RefitFor<T>() workaround.

What is safe to call

We captured the exact URL each method now builds. Four of the five are clean:

Client	Methods	Status
Organizations.Summary.SwitchPower	...HistoryAsync	Clean, supports t0 / t1 / timespan
Organizations.Appliance.Uplinks.Usage	...ByNetworkAsync	Clean
Organizations.Wireless.Devices.Latency	ByClient, ByDevice, ByNetwork	All clean
Organizations.Wireless.Devices.PacketLoss	ByClient, ByDevice, ByNetwork	All clean

Note that apart from SwitchPower, these currently only accept organizationId. There is no t0 / t1 / timespan / networkIds[] on the signatures, so you will get the API default window and org-wide scope. That is a coverage gap rather than a defect, but worth knowing before you build around them.

ChannelUtilization is a mixed bag, and this matters to you specifically since it is the sync you had disabled:

• GetOrganizationWirelessDevicesChannelUtilizationsByDeviceAsync takes only organizationId and is clean. Use this one.
• The other three take a bare, required string networkId that is not part of the route, so Refit serialises it as ?networkId=N_1234. The Meraki endpoints expect networkIds[], so these will either return a 400 or silently return unfiltered data. Because the parameter is required, there is nothing to hint that the filter is not being applied.

That is pre-existing and was not introduced by this fix. Correcting the signature needs verification against the live API, so it is tracked on #357 rather than rushed into this release.

You found the tip of something larger

A reflection walk of the whole section tree showed a further 82 Refit clients and 4 sub-section objects still left null by the constructor, from the same root cause you identified: a hand-maintained initializer mirroring a large section tree, with nothing asserting it is complete.

Two interfaces also carry the exact same parameter typo you found, and are still unusable: IOrganizationsVpnSiteToSiteIpsec and ICameraCustomAnalyticsArtifacts.

All of that is now tracked in #357, along with a proposed structural fix so the class of bug stops recurring. If you hit another NullReferenceException on a section property, it is very likely one of the 82, and the list in #357 will tell you which.

Thanks again for taking the time to write this up properly. It turned out to be worth considerably more than the five endpoints you reported.