feat: map the Appliance response members from the 1.74.0 gap report

[danielabbatt]

Rebased onto main on 2026-09-29 (main builds as 1.70.147). Merges as 1.74.9.

Before merging, retarget the base to main. Base branches are not auto-deleted in this repo, so GitHub will not retarget for you, and merging into the old base leaves the work off main (what happened to #413). Merge only after #418 is on main, with a merge commit; do not squash, rebase or click Update branch.

Stacked on #418, in the chain that starts at #415

Base is feat/map-sm-members. Merge the chain in order with merge commits, then retarget this to main. Changelog label 1.74.9 assumes that.

What

Third per-area batch from gap-report-v1.74.0.md: 18 Appliance members the spec documents that the models lacked, across 12 classes.

Member	Type
AppliancePort.Sgt, Vlan.Sgt, SiteToSiteVpn.Sgt	new AppliancePortSgt {id, enabled}, VlanSgt {id}, SiteToSiteVpnSgt {enabled} (the three differ in the spec)
LanConfiguration.Vrf, Neighbor.Vrf, TrafficUplinkPreference.Vrf	existing VlanVrf {id, name}: identical shape, reused rather than triplicated
SiteToSiteVpn.HostTranslations	new SiteToSiteVpnHostTranslation {name, local, remote} + SiteToSiteVpnHostTranslationAddress
ThirdPartyVpnPeer.EcmpUplinkConfigs	new ThirdPartyVpnPeerEcmpUplinkConfig {id, wan, privateSubnets, ebgpNeighbor} + ThirdPartyVpnPeerEcmpUplinkConfigEbgpNeighbor
NetworkUmbrellaAccountConnectResponse.Umbrella	new NetworkUmbrellaAccountConnectResponseUmbrella containing NetworkUmbrellaAccountConnectResponseUmbrellaOrganization {id}
StaticRoute.IpVersion, ThirdPartyVpnPeerEbgpNeighbor.ReceiveLimit	int?

Access follows the spec: read/update where the member is on a PUT body, read-only otherwise.

Two corrections (breaking in the type-system sense; both always came back empty)

1. VpnStatus.ThirdPartyVpnPeers was List<ThirdPartyVpnPeers>, the configuration wrapper ({peers}), so each status entry deserialized to an object with an empty Peers. The API sends {name, publicIp, reachability}; now List<VpnStatusThirdPartyVpnPeer>.
2. UpdateOrganizationApplianceDnsLocalRecordAsync returned OrganizationApplianceDnsLocalRecordsProfile ({id} only). The API returns the record; it now returns OrganizationApplianceDnsLocalRecordsResponse, matching the create and list methods fix: correct response shapes and member names that could never bind #416 fixed.

Verification

dotnet build Meraki.Api.slnx -c Debug   Build succeeded, 0 Error(s), 6 pre-existing CS0618 warnings
Meraki.Api.Test (Data namespace)        Total: 41, Errors: 0, Failed: 0   (7 new in ApplianceMemberTests)
Meraki.Api.Test (Workflows)             Total: 12, Errors: 0, Failed: 0

All edited files kept their BOM state and line endings. No code outside Interfaces/Data referenced the changed members.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 9 complexity

Metric	Results
Complexity	9

View in Codacy

AI Reviewer: run a review on demand. To trigger the first review automatically, go to your organization or repository integration settings. AI can make mistakes. Always validate suggestions.

_{TIP This summary will be updated as you push new changes.}

[danielabbatt]

Looks good