Bug Report: createNetworkApplianceVlan drops DHCP boot fields

[SalnikovAndrey]

Bug Report: createNetworkApplianceVlan drops DHCP boot fields

Describe how you confirmed the issue is with the library, and not with the API itself, or a server-side issue of some other kind.

I verified that my restore logic builds a payload containing dhcpBootNextServer and dhcpBootFilename, but the Meraki Python SDK filters those fields out before sending the request. In meraki/api/appliance.py, createNetworkApplianceVlan() whitelists body params and does not include dhcpBootNextServer or dhcpBootFilename, even in meraki 2.1.0. As a result, the API receives dhcpBootOptionsEnabled: true without dhcpBootNextServer, which triggers Boot next-server option must not be empty. This indicates a client-side filtering bug in the SDK, not a server-side issue. (I have not reproduced with Postman/requests yet.)

Python version installed

Python 3.12.4 (venv)

Meraki library version installed

meraki 2.1.0

Have you reproduced the issue with the latest version of this library? And with the latest version of Python?

Yes, reproduced on meraki 2.1.0 and Python 3.12.4.

OS Platform

macOS (Darwin 25.2.0)

Describe the bug

createNetworkApplianceVlan fails when dhcpBootOptionsEnabled is true because the SDK strips out dhcpBootNextServer and dhcpBootFilename from the payload. The API then returns Boot next-server option must not be empty. This appears to be a library bug because those fields are valid and should be passed through when provided.

How can we replicate the problem you're reporting?

Docs: https://developer.cisco.com/meraki/api-v1/#!create-network-appliance-vlan

1. Call createNetworkApplianceVlan with dhcpBootOptionsEnabled=True and provide dhcpBootNextServer + dhcpBootFilename.
2. Observe that the SDK drops those fields from the outgoing payload.
3. API returns 400 Bad Request: Boot next-server option must not be empty.

Expected behavior

The SDK should pass through dhcpBootNextServer and dhcpBootFilename so the VLAN is created successfully with DHCP boot options.

Repro call:
dashboard.appliance.createNetworkApplianceVlan(
networkId="N_XXXXXXXXXXXX",
id="4",
name="Four",
subnet="192.168.4.0/24",
applianceIp="192.168.4.1",
dhcpHandling="Run a DHCP server",
dhcpLeaseTime="30 minutes",
dhcpBootOptionsEnabled=True,
dhcpBootNextServer="192.168.4.3",
dhcpBootFilename="ipaddress.txt",
dhcpOptions=[]
)

Additional context

• The API spec supports dhcpBootNextServer and dhcpBootFilename for VLANs.
• The payload is correct before it reaches the SDK; the SDK strips it.
• This blocks restore workflows for VLANs that use DHCP boot options.